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(57) Abstract 

Detecting (206) attempted intrusions in a telecommunications signaling network (202) and assessing (212) the vulnerability of the 
network to the attempted intrusions. Intrusion rules are applied to received messages in the network in real-time, using a known protocol for 
the network in order to detect anomalies tending to indicate an attempted intrusion. In order to assess the vulnerability of the network, the 
vulnerability rules are applied to rankings of particular parameters relating to elements in the network. The rankings pro V1 de an md^at.on 
of susceptibility of a network element to an attempted intrusion relative to other network elements. 
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SYSTEM FOR INTRUSION DETECTION AND 
VULNERABILITY ANALYSIS IN A 
TELECOMMUNICATIONS SIGNALING NETWORK 

5 Technical Field 

The present invention relates to a system and method for detecting intrusion 
into, and for assessing the vulnerability of, a telecommunications signaling network. 
Background Art 

Telecommunications signaling networks are susceptible to intrusion, meaning 

10 that a person may use software or physical means to cause disruption or denial of 
service within the network. For example, a person may use software operating on a 
computer in an attempt to seize control of a particular node or link in the network 
and consequently cause a disruption or denial of service. As another example, a 
person may attempt to take physical control of an entity in the network, such as a 

15 link, resulting in a disruption or denial of service. 

These intrusions create an undesirable situation for communications service 
providers and for customers using the network. In particular, the disruptions or 
denials of service may inconvenience customers and potentially cause a loss in 
revenue for the communications service provider. When a disruption occurs, a 

20 service provider may attempt to locate the disruption and determine a cause of the 
intrusion. However, in that case the service provider only obtains an indication of 
the intrusion after it has already caused a disruption and thus cannot anticipate such 
an intrusion before it occurs. In addition, the server provider may not necessarily 
know in advance which portions of the network are most susceptible to an intrusion 

25 and thus not know how to best monitor the network for potential intrusions. 

Accordingly, a need exists for detection of intrusion in a telecommunications 
signaling network, potentially in real-time, and for analysis of the vulnerability of the 
telecommunications signaling network to an intrusion. 
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Brief Description of the Drawings 

PIG i is a diagram of an exemplary telecommunications signaling network and 

associated machine for monitoring the network; 
PIG. 2 is a diagram of software modules operating on the machine shown in FIG. 
5 1 for implementing an embodiment consistent with the present invention; 

FIG. 3 is a flow chart of an exemplary process for monitoring a 

telecommunications signaling network for intrusion detection; 
PIG. 4 is a flow chart of an exemplary process for determining vulnerability of a 
telecommunications signaling network to potential intrusion; 
10 FIG. 5 is an exemplary user interface for entering set-up information for an 
intrusion detection process; 
FIG. 6 is an exemplary user interface for displaying status information related to 

an intrusion detection process; and 
PIG. 7 is an exemplary user interface for displaying information related to a 
15 vulnerability analysis of a telecommunications signaling network. 

Disclosure of Invention 

Apparatus and methods consistent with the present invention provide 
indications of attempted intrusions in a telecommunications signaling network and 
the vulnerability of particular elements in the network to attempted intrusions. 
20 An apparatus consistent with the present invention receives messages related 

to communications in a telecommunications signaling network. The apparatus 
applies intrusion rules to the messages in order to order to detect anomalies in the 
messages, and it reports an indication of the detected anomalies. 

Another apparatus consistent with the present invention receives rankings for 
25 particular parameters related to elements of a telecommunications signaling network. 

The apparatus applies vulnerability rules to the rankings in order to 
determine a likelihood of an attempted intmsion into the corresponding elements of 
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the telecommunications signaling network, and it reports an indication of the 
likelihood of the attempted intrusions. 

A method consistent with the present invention includes receiving messages 
related to communications in a telecommunications signaling network. Intrusion 
5 rules are applied to the messages in order to order to detect anomalies in the 
messages, and an indication of the detected anomalies is reported. 

Another method consistent with the present invention includes receiving 
rankings for particular parameters related to elements of a telecommunications 
signaling network. Vulnerability rules are applied to the rankings in order to 
10 determine a likelihood of an attempted intrusion into the corresponding elements of 
the telecommunications signaling network, and an indication of the likelihood of the 
attempted intrusions is reported. 
Best Mode for Carrying Out the Invention 

Apparatus and method consistent with the present invention provide 
15 indications of attempted intrusions in a telecommunications signaling network and 
the vulnerability of particular elements in the network to attempted intrusions. 
Although both intrusion detection and vulnerability analysis are described, each is 
typically a separate entity, and the operation of one is not necessarily dependent on 
the other. 

20 Attempted intrusions refers to attempts to disrupt or deny service in the 

network or to otherwise tamper with the network. Intrusion rules are applied to 
received messages in the network, typically in real-time and using a known protocol 
for the network, in order to detect anomalies tending to indicate an attempted 
intrusion. Messages refers to any particular data element transmitted in the network. 

25 For example, standard telecommunications signaling networks use messages in order 
to provide particular telephone-related services to customers. Intrusion rules refers 
to any criteria or methodology for detecting the anomalies. Indications of the 
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attempted intrusions may be presented, for example, in a user interface that includes 
a topological representation of a monitored portion of the network. 
In order to assess the vulnerability of the network, vulnerability rules are applied to 
rankings of particular parameters relating to elements in the network. Vulnerability 

5 rules refers to any criteria or methodology for processing the rankings to provide 
indications of likelihood of attempted intrusions with respect to particular elements 
in the network. Rankings refers to any information providing an indication of 
susceptibility of a particular network element to an attempted intrusion relative to 
one or more other network elements. A user interface may be presented in order to 

10 receive the rankings and to display indications of the vulnerability of elements in the 
network. 

FIG. 1 depicts a data processing system 100 suitable for practicing methods 
and systems consistent with the present invention. Data processing system 100 
includes a machine 101 for intrusion detection and vulnerability analysis, connected 

15 to a network 107 such as a private or public telecommunications signaling network. 
Machine 101 includes a memory 102, a secondary storage device 104, a processor 
105 such as a central processing unit, an input device 106, and a display device 103. 
Memory 102 and secondary storage 104 may store applications and data for 
execution and use by processor 105. Input device 106 may be used to enter 

20 information and commands into machine 101, and display device 103 provides a 
visual of information in machine 101. 

Although machine 101 is depicted with various components, one skilled in the 
art will appreciate that this computer can contain additional or different components. 
Additionally, although machine 101 is shown connected to network 107, 

25 machine 101 may be connected to other networks, including other wide area 
networks or local area networks. Furthermore, although aspects of the present 
invention are described as being stored in memory, one skilled in the art will 
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appreciate that these aspects can also be stored on or read from other types of 
computer program products or computer-readable media, such as secondary storage 
devices, including hard disks, floppy disks, or CD-ROM; a carrier wave from the 
Internet; or other forms of RAM or ROM. In addition, the computer-readable media 

5 may include instructions for controlling a computer system, such as machine 101, to 
perform a particular method. 

FIG. 2 is a diagram of software modules operating on the machine shown 
in FIG. 1 for implementing an embodiment consistent with the present invention. 
These modules include modules 200 for intrusion detection and modules 201 for 

10 vulnerability analysis of a network 202. Network 202 is a standard Signaling 

System 7 (SS7) protocol network and illustrates an example of network 107. Other 
examples of network 107 include an integrated Services Digital Network (ISDN) 
and an X.25 network. A monitoring analyzer module 204 receives real-time data 
203 from network 202. Real-time data 203 may include messages transmitted in an 

15 SS7 protocol network or other type of network. Monitoring analyzer 204 packages 
the data for analysis and forwards it in real-time to a data collector process module 
205. Data collector process module 205 parses the received data to remove 
information from the messages not necessary for intrusion analysis, and it reformats 
the parsed messages to a consistent format to facilitate intrusion analysis. Data 

20 collector process module 205 alternatively may receive preformatted SS7 protocol 
messages 2 14 from a test file 208 for use in testing or verifying the intrusion 
detection capabilities of the system. 

An intrusion detection process module 206 receives the reformatted messages 
and performs processing of the messages to detect intrusion. In particular, it applies 

25 intnision detection rules to the messages in order to detect anomalies in the messages 
or other events tending to indicate an attempt at intrusion into the network or to 
otherwise tamper with the network. These rules may be stored in memory or in a 
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database such as memory 102 or secondary storage 104, or they may be implemented 
in hard-wired logic. 

Examples of these rules are provided in the Appendices. After or during 
performance of the intrusion detection processing, intrusion detection process 206 
5 outputs the results to an intrusion log 209 that maintains a time-stamped history of 
the processing in the form of a textual listing, and it outputs the results to a display 
management process module 207. The textual listing may be printed in hard copy 
form using a printer connected to machine 101 or may be displayed on display 
device 103. 

10 Display management process module 207 formats the processed data for display 
within a topology status display 210, which may be displayed by display device 103. 
Topology status display 210 provides a visual indication of the status of the 
monitored network and indications of intrusions into the network, and an example of 
a user interface for the topology status display is described below. 

15 A topology database 215 stores information representing a topology or 

interconnectivity of network 202. Intrusion detection process module 206 and 
display management process module 207 may access database 215 in order to 
retrieve the topology information and use it in the processing performed by those 
modules. In addition, topology database 215 may store the rules used by intrusion 

20 detection process module 206. Topology database 215 may correspond to secondary 
storage 104, and it may be implemented, for example, with a Sybase database. 

Vulnerability analyzer modules 201 include a vulnerability analysis process 
module 212 and a display management process module 21 1. Vulnerability analysis 
process module 212 receives the network topology information from topology 

25 database 215, and it applies vulnerability rules to the topology information in order 
to determine the vulnerability of elements in network 202 to intrusion attempts. 
Examples of these rules are provided in the Appendices. Vulnerability analysis 
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process module 212 outputs the results of its analysis to a vulnerability log 213, 
which maintains a time-stamped textual history of the processing in the form of a 
textual listing, and it also outputs the results to a display management process 
module 21 1. The textual listing may be printed in hard copy form using a printer 

5 connected to machine 101 or may be displayed on display device 103. 

Display management process module 211 operates in a similar manner as 
module 207. In particular, it receives output results from module 212 and formats 
the received data for presentation in a user interface by display device 103. An 
example of a user interface for presenting the vulnerability process data is described 

10 below. 

FIG. 3 is a flow chart of an exemplary process 300 for monitoring a 
telecommunications signaling network for intrusion detection. Process 300 may be 
implemented on machine 100 operating under control of intrusion detector modules 
200 and module 204. In process 300, the system receives communication messages 

1 5 from the network such as SS7 messages provided by monitoring analyzer module 
204 from network 202 (step 301). The system parses and formats the messages 
using data collector process module 205 (step 302). Intrusion rules are applied by 
intrusion detection process module 206 to the formatted messages to detect 
anomalies or other events in the network tending to indicate an attempted intrusion 

20 (step 303). The results are reported and potentially displayed by display device 103, 
using intrusion log 209 or topology status display 210, to provide a visual indication 
of attempted intrusions into network 202 an potentially the status of the network 
(step 304). 

FIG. 4 is a flow chart of an exemplary process 400 for determining 
25 vulnerability of a telecommunications signaling network to potential intrusions. 
Process 400 may be implemented on machine 100 operating under control of 
vulnerability analyzer modules 201 . Process 400 operates by using static rankings 
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processed as input weightings according to particular rules to generate further 
rankings. The process may be performed iteratively such that the output from one 
particular processing rule may be input as a ranking to another rule. The boxes in 
process 400 represent static rankings for particular parameters related to the network, 
5 and the circles represent vulnerability rules for processing the rankings. Examples 
of these vulnerability rules are provided in the Appendices. 

Examples of parameters providing rankings as particular weightings for 
processing by vulnerability rules include the following: a percent utilization 401, a 
number of links 402, a percent traffic external 403, a monitoring 404, a screening 
10 405, a media type 406, a transmission provider 407, a services 41 1 , a user service 
rank 413, a connectivity by service 414, a node occupancy by service 416, and a user 
SSP ranking 418. These parameters are explained in the Appendices, and different 
or additional parameters may be used to perform a vulnerability analysis of a 
telecommunications signaling network. 
15 Each parameter produces a static rank, in this example a particular number, 

to be processed by vulnerability rules. A functional capacity rank rule 408 receives 
inputs from parameters 401-404 and produces a result according to the function of 
rule 408. A security rank rule 409 receives inputs from parameters 404 and 405 and 
produces a result according to the function of the 409. A physical access rank rule 
20 410 receives inputs from parameters 406 and 407 and produces a result according to 
the function of rule 410. A functional services rank rule 412 receives as input 
parameters 41 1 and 404, as well as the output from rule 409, and produces a result 
according to the function of rule 412. The process continues iteratively as an 
inherent link ranks rule 420 receives the outputs from rules 408, 409, 410, and 412, 
25 and produces a result according to the function of rule 420. Rule 420 provides one 
input to a most critical links rule 422. 
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The following provides the other input to most critical links rule 422. An SCP 
criticality rule 415 receives as inputs parameters 413, 414, and 416, and it produces a 
result according to the function of rule 415. An STP criticality rule 417 receives as 
inputs parameters 414 and 416, and the output of rule 415, and it produces a result 
5 according to the function of rule 417. An SSP criticality rule 419 receives as inputs 
parameters 414, 416, and 418, and it produces a result according to the function of 
rule 419. As the process proceeds iteratively, a most critical nodes rule 421 receives 
the outputs from rules 417 and 419, and it provides the other input to most critical 
links rule 422. Therefore, as a result of this iterative process, the result of rule 422 
10 provides an indication of the most vulnerable link in the network, and the result of 
rule 421 provides an indication of the most vulnerable node in the network, the 
phrase "most vulnerable" meaning that it is the element most likely to be susceptible 
to an attempted intrusion. 

FIG. 5 is an exemplary user interface 500 for use in entering set-up 
15 information for an intrusion detection process such as process 300. User interface 
500 may be displayed on display device 103. User interface 500 includes a first 
section 501 used to receive threshold values for detection of intrusion, a second 
section 502 used to identify a point in the network from which the intrusion 
detection process receives data, and a third section 503 used to save and retrieve set- 
20 up information so that a user need not repeatedly enter the same set-up information. 
A user may enter relevant information into sections 501 and 502 using input device 
106, and section 502 identifies where data 203 originates in network 202 and thus 
provides a reference point for performing an intrusion detection process. The 
location where the data originates may typically be changed so that a user may 
25 monitor the network from varying locations, and the location may be selected by 
using, for example, results of a vulnerability analysis. 
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FIG. 6 is an exemplary user interface 600 for displaying status information 
related to intrusion detection such as information produced by process 300. User 
interface 600 may be displayed on display device 103. User interface 600 includes a 
main section 601 for displaying a topological representation of a portion of the 

5 network and including information indicative of various conditions in the network. 
These conditions may provide an indication of attempted intrusions in the network. 
A displayed node 602 corresponds to the node identified in section 502 of user 
interface 500, and node 602 represents the node from which the system receives 
data. Other displayed nodes 603 and 604 represent nodes located one link away 

10 from node 602 in the monitored network. Each of the displayed nodes includes 
associated point codes and link information, displayed adjacent the corresponding 
node. Section 601 also displays lines between the nodes, and the lines represent the 

corresponding links. 

When a user selects a particular displayed node the system displays a section 

15 605 for presenting node information relating to the selected node. The node 

information may include a ranking determined by a vulnerability analysis. When a 
user selects a displayed link, the system displays a section 606 for presenting static 
information relating to the selected link, including link attributes, an anomaly 
history, and a Iinkset selection label. The anomaly history may correspond to history 

20 log 209. The user may select a particular node or link by, for example, using a 
cursor-control device to "click on" the particular node or link. 

The system may optionally present the links in different colors to provide 
indications of varying conditions. For example, it may present the links using the 
following colors: green for a normal condition; yellow for a minor condition; orange 

25 for a major condition; red for a critical condition; and gray to indicate that the link is 
not monitored. The various conditions may be determined by the detected anomalies 
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from module 206 and particular predefined thresholds, which are further explained 
in the Appendices. 

PIG. 7 is an exemplary user interface 700 for displaying information related to 
a vulnerability analysis such as process 400. User interface 700 may be displayed on 
display device 103. User interface 700 includes various sections in which a user 
may enter rankings for use by the rules in process 400. For example, it includes a 
section 701 to receive values for a services ranking and a section 702 to receives 
values for an SSP ranking. A user may select an appropriate tab 703 on a menu bar 
to view the corresponding section 701 and 702. User interface 700 may include 
additional tabs 703 and sections for receiving information concerning other rankings. 

The accompanying Appendices, which are incorporated in and constitute a 
part of this specification, include the following: Appendix A includes a system 
overview for an exemplary intrusion detection process and vulnerability analysis; 
Appendix B includes a software user's manual for an exemplary intrusion detection 
15 process and vulnerability analysis; Appendix C includes a software design 

document for an exemplary intrusion detection process and vulnerability analysis; 
Appendix D includes a description of exemplary vulnerability analysis attributes 
and algorithm, including vulnerability rules; and Appendix E includes a description 
of exemplary intrusion detection algorithms including intrusion rules. 



10 



1 1 



WO 00/07312 



PCI7US99/I7408 



APPENDIX A 
SYSTEM OVERVIEW 



TABLE OF CONTENTS 



1. SCOPE „ 3 

1.1 System Overview 3 

1.2.1 Vulnerability Analysis Tool. j 

1.2.2 Intrusion Detection Tool... j 

1.2.3 Network Topology Database 4 

2. REFERENCES 4 

3. INTRUSION DETECTION TOOL 4 

3. 1 Concept of Operation 4 

3.1.2 Concept of Execution 4 

3.1.3 Interfaces 5 

3.1.3.1 Graphical User Interface (GUI) 5 

3.1.4 Data Collector <5 

3.1.4.1 Concept of Execution 6 

3.1.4.3 Test Files 7 

3.1.5 Network Topology Database g 

4. VULNERABILITY ANALYZER 8 

4.1 Concept of Execution g 

4.1.1 Node Evaluation 9 

4.1.2 Link Evaluation p 

4.2 Interfaces 10 

4. 2. 1 User Interface 10 

4.2. 1 . 1 Control and configuration 1 0 

4.2.1.2 Analysis Results 1 1 

4.2.2 Network Topology Database. 1 1 

5. NETWORK TOPOLOGY DATABASE ; . n 

5. 1 Concept of Execution 1 1 

5.1.2 Interfaces 1 1 

5.1.2.1 GUI/Intrusion Detector 1 2 

5. 1 .2.2 Vulnerability Analyzer 1 2 



12 

SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 



PCT/US99/17408 



APPENDIX A 
SYSTEM OVERVIEW 

LIST OF FIGURES 

Figure 3-1 - Intrusion Detector Context Diagram 

Figure 2 Data Collector Path 

Figure 3: Vulnerability analysis Logic Flow 

Figure 4-4 - Vulnerability Analyzer Context Diagram 

Figure 5-5 - Network Topology Database Domain Diagram 



13 



SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 



PCT/US99/17408 



APPENDIX A 
SYSTEM OVERVIEW 



1. Scope 

1.1 System Overview 

Signaling System 7 (SS7) is the Control Service Layer of the Public Switched Telephone Network (PSTN); 
therefore, an attack on the SS7 network can cause PSTN service disruption .-denial without undertaking a 
physical arrack. An attack on the SS7 network can actually be accomplished through the manipulation and 
exploitation of the SS7 message protocol itself by means of message insertion onto the network signaling 
links. The SS7 network is inherently vulnerable to such attacks for two (of several ) reasons: the SS7 
protocol does not include Security and SS7 was built for robustness and thus, is very forgiving to 
anomalous states. 

The System includes two tools: an SS7 Intrusion Detection Tool and a Vulnerability Analysis Tool. 

The operational concept is that the intrusions would be well organized with the intent of service disruption 
service denial through insertion of SS7 messages into the SS7 message traffic stream. Due to the equal 
access' provision of the 1996 Telecommunicanons Reform Act, concern within the PSTN industry has 
increased over the fear of new and unknown carriers entering the market. These unknown ennrics pose a 
new threat to the SS7 network since they can demand full interconnection capabilities into the existing SS7 
network while providing only limited visibility into their operations. Hence a modestly funded operator 
could gain full access the SS7 network for illicit purposes. 

1.1.1 Vulnerability Analysis Tool 

The purpose of the System SS7 Network Vulnerability Analysis Tool is to allow the user to determine 
which network elements in the SS7 Network are most vulnerable to an SS7 Message Insertion attack 
designed for Service Disruption/ Denial. As the analysis relates to Intrusion Detection, the results are used 
to indicate where Intrusion Detection resources should be applied in the Network based on the evaluated 
preferences supplied by the operator. 

The Vulnerability Analysis Tool uses an SS7 Network Topology database which contains a set of attributes 
describing all of the SS7 Network Elements (links and nodes). These Network Element attributes are 
evaluated against a set of attribute weighting factors and against formulas relating combinations of 
attributes. The user has the ability to modify attribute weightings to tailor the analysis for specific 
preferences. 

1.1.2 Intrusion Detection Tool 

The real-time SS7 Intrusion Detection Tool provides SS7 link monitoring and analysis of SS7 message 
traffic for anomalous events which indicate possible intrusion into the message stream. The Intrusion 
Detection algorithms apply rules based logic and event thresholding against the message traffic stream. The 
logic evaluates message sequence and timing irregularities, inconsistent parameter values, and exceeded 
thresholds of message type occurrences. 

The User Interface includes of a Network Topology display of the monitored network nodes and 
corresponding signaling linksets. The iinkset status is indicated to the user by coloring the link icons 
corresponding to the severity of the detected anomaly. The detected anomaly text is displayed to the user in 
an Alarm Status window. 
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APPENDIX A 
SYSTEM OVERVIEW 

1.1 j Network Topology Database 

One of the goals of the system program has been to hac, ,h- , ■ 

In order to accomplish th.s. the'system has £2^^$£^* 7 ** »« openmoos. 

topology data and operat.onai sunst.es into the system database °P era "°<» (TELOPS) network 

2. References 

The fo.low.ng documents prov.de background lt.format.on and are incorporated here, by reference: 

JJJLE 



DOCUMENT No 
[1) ANSI Tl.l 1 1-1992 



[2] ANSI Tl.l 13-1995 



Signaling System Number 7. ISDN User Pan I NI »i » 
National Standards Institute [nc. 1995 ^ 



3. Intrusion Detection Tool 
3.1 Concept of Operation 

The Intrusion Detector examines the SS7 network mM^o j j 

ind.ca,e message insertions into the SS7 stream SuTh coSLol, H anomalous «»ditions that mav 
The Intrusion Detector operates in the manner of a network m!> _ 

user uuerface (GUI) prov.des a topological v. J 0 f Z7nL^Tl ™ erefore ' ^ ^ph.cal 

tnd.ca.ed to the user by co.onng tL £ on to^^St^ « 

3.1.1 Concept of Execution 

The Intrusion Detector analyzes each new messaee receive 

information contamed within the newly received SS7 m««~ l^T? Alon S *e 

prev^usly captured SS7 messages, as we., as ^^^^ "*» -m 

" ^SeT^^ agamSt tOP ° ,0gy Ulf0r ™ tl0n « - P0« -des cons.stent •«* how the nodes 

reacring to the intrus.on message. mtrUS '° n meSSage itSe,f or " * result of the nework 

The following conditions are tested at different levels of the protocol: 
a) 



ISDN User Part (ISUP) messages (See reference 161) 
0 Improper RELEASE 
if) Improper BLOCKING and/or CIRCUIT GROUP BLOCKING 
■») Improper RESET and/or CIRCUIT GROUP RESET 

iv) Improper FACILITY DEACTIVATED 

v) Improper UNIDENTIFIED CIRCUIT IDENTIFICATION CODE 
b) Message Transfer Part (VTTP) messages 

|) ^proper CHANGEOVER (including Emergency Changeover) 
") AU unproper MANAGEMENT INHIBITING "^cover; 
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iii) Improper SIGNALING ROUTE MANAGEMENT (Transfer- Prohibited and 
Transfer-Restricted only) 



Whether there was an anomaly detected or not. the current SS7 message is finally stored, to be used in the 
next anomaly test. " 

3,1.2 Interfaces 

The context diagram, shown in Figure 3-1. identifies the mulriple subsystem processes The followmp 
subsections address these interfaces, with the exception of the Data Collector input 



Data 
Collector 



— SS7 Messages 




Figure 3-1 - Intrusion Detector Context Diagram 
3.1.2.1 Graphical User Interface (GUT) 

The GUT is the mechanism used to allow the system operator to configure the system, start and stop 
operations and provides the message analysis results on a topological status display The design reflects a 
network management type display to the user. As with such systems, a network topology display depicts 
the network elements (in this case SS7 nodes and links). 

Upon initialization of this process, the GUI retrieves configuration and network topology information from 
the corresponding databases to construct a view of the local SS7 network infrastructure (nodes sienal 
links, etc.), relative to the link being monitored. 

This view is used to communicate to the operator the current state of each link of that local network All 
direct links, to the link being monitored, are represented by a dashed line. The link being monitored is 
represented by a solid line to differentiate itself. 

Network status is displayed by coloring the links. Node information and link status windows urovide 
greater detail of the network. . v 

3.1.2.1.1 Control and configuration 
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In response to a control message from the GUI subsystem, the Intrusion Detector accepts the following 
information from the GUI message queue for configuration and control: 



a ) STA RT operation 

b) STOP operation 

c) PAUSE operation 

d) Send Status/Statistic data 

e) Threshold and parameter values for algorithms 

3.1.2.1.2 Status and Statistics 

When any of the predefined anomaly rules or a combination of these rules are satisfied (indicating an 
anomaly), a message is sent to the GUI input queue for display. The message will indicate the following 
information about the anomaly: 



a) the SS7 message (protocol analyzer output format) 

b) a time stamp generated by the Data Collector 

c) the rule(s) fired that caused the anomaly report 

d) the link affected and the color code indicating the anomaly ranking (GREEN'. YELLOW 
ORANGE or RED) as displayed to the operator 



3.1 J Data Collector 

The Data Collector accepts SS7 message data from both a protocol analyzer and a test file source. It is a 
real-time operation, which is comprised of thee primary functions: the Message Parser, the input stream 
multiplexer and the output message queue. 

The complexity of this subsystem is minimal, however, partitioning of the collection funcnonality enables 
the possibility of porting it to another processor, if the performance is required. Also, it isolates the impact 
to the other subsystems if there are hardware changes to the front-end collection method (e.g., change of 
protocol analyzer). 



3.1 J. 1 Concept of Execution 

The Data Collector can manage inputs from a live message stream from a protocol analyzer source, or from 
a test file, or both. When accepting inputs from a protocol analyzer, the Message Parser is invoked to 
reformat the SS7 data into a condensed format needed by the Intrusion Detector process. When live data is 
combined with test file data, the test file data must be multiplexed into the live data stream. This combined 
mode is useful since it aUows injection of test SS7 intrusion messages against a background of live nominal 
SS7 messages. In this manner, the Intrusion Detector can be tested against real message traffic (and 
message traffic volume) and still be able to test specific intrusion scenarios without the need to inject 
anomalies onto the actual network. 
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Protocol 
Analyzer 



Turbo- 7 
Format 



TCP IP 




System 
Format 




Figure 2 Data Collector Path 



J. 1 J. 1.1 Protocol Analyzer 

The protocol analyzer uses an 1NET Turbo-7 with an MSU Forwarding option. The MSU Forwarding 
feature provides TCP IP forwarding capability of the collected SS7 Message Signal L'nits (MSUs). 

The Turbo- 7 protocol analyzer outputs the SS7 as received in time sequence from all of the monitored SS" 
links. Each message has a header including of the port and times tamp followed by the raw SS7 message. 
The Turbo- 7 outmessage format is shown in the Software User's Manual. 

3.1J.1.2 Message Parser 

The Message Parser operates as a go-between from the protocol analyzer and the Intrusion Detector 
process. The input from the protocol analyzer is received over a TCP/IP socket interface. Each message is 
analyzed and reformatted by message type, retaining only those parameters required by the Intrusion 
Detector process. If addinonaJ message types and/or message parameters arc desired or if different message 
;ollecnon hardware is used, the Message Parser can be modified without impact to follow on processes. 

3.1J.2 Test Files 

The test files allow the Intrusion detector to run in a testing / simulation configuration when it is not 
desired or when it is unpractical to have a live network connection. The test file is simply a concatenated 
set of SS7 messages in the data format output by the Message Parser. The messages can represent data 
from any protocol analyzer port with any values desired in the data fields. Therefore, test files can be set 
up to emulate normal SS7 network traffic on a variety of signaling links with embedded anomalies. 

Although the test files use data formats output by the Message Parser, there is one distincnon: the 
tunestamp field. The test file times tamp field represents a tune delay vice an absolute time. This 
convennon was established in order to accommodate both a real time aspect to the test data tuning and to 
facilitate test file message injecnon into the live data stream. Test file formats are described in the Input 
MSU Test File section of the Software User's Manual. 
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3.1 .4 Network Topology Database 

The Network Topology Database provides the intrusion detection algorithms with the required relevant 
infrastructure data of the SS7 network. The network topology information and its format, is described in 
the Software User's Manual. 

The topology data is used by the Intrusion Detector to perform several types of legitimacy checks of the 
message point codes. Basically, checks are made to ensure that the messages are originating from 
legitimate locations and are arriving over the proper routes. These checks are based on message type. 



4. Vulnerability Analyzer 

The primary responsibility of the Vulnerability Analyzer is to evaluate an SS7 infrastructure data and 
determine the locations most vulnerable to SS7 network intrusion. The goal was to produce a tool that 
evaluated the network vulnerability in the same manner as a network analyst evaluates the network. To 
demonstrate the ability to evaluate different operational priorities, the user is able to designate certain 
evaluation parameters. 

4.1 Concept of Execution 

In response to a START message sent to its message queue from the User Interface, the analyzer retrieves 
network topology information from the database. These Network Element attributes are evaluated against a 
set of attribute weighting factors and against formulas relating combinations of attributes. The attributes are 
stored in the topology database whereas the rankings are stored in a configuration file. (Refer to the 
Software Users Manual for descriptions.) 

The user has the ability to modify attribute rankings to tailor the analysis for specific evaluation 
preferences such as: 

• select whether to evaluate Advanced Intelligent Network (AIN) services or Plain Old Telephone 
Service (POTS) 

• when AIN is selected, rank the AIN services relative to each other to indicate the service(s) that have 
greater importance to the evaluation 

• select specific SSP locations and rank those locations higher than nominal to indicate customerf s) 
locations that may have greater importance to the evaluation (such as government or business groups) 

The evaluation formulas have been implemented within the software. Below is an outline of the analysis 
logic that is performed. Every attribute of every node and link within the network is evaluated. A base 
score of each node and link is established and is subsequendy modified at each stage of the evaluation. The 
influence to the vulnerability score of each attribute is determined by the value of the attribute and on the 
importance ranking of that attribute. The rankings act as a weighting applied to the attribute value within 
the formula and control how much of a modifier of the attribute to the overall vulnerability score. As each 
node and link is evaluated, combinations of attributes are also evaluated and ranked. 

The criteria for determining most critical node is that which attains a score of 10 or above. If more than one 
node is identified as exceeding a score of 10 than each node is listed with the corresponding list of 
vulnerable links to that node. (This is due to determining the number of hops to the critical node from each 
link). 
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Figure 3: Vulnerability Analysis Logic Flow 



4.1.1 Node Evaluation 

The nodes are primarily evaluated to determine thetr cnncality to the overall network operations and thus 
desirability to attack. 

In the case of POTS evaluation, each STP pair is evaluated based on the number of SSPs directly 
connected to the STP and the volume of the SS7 traffic routed through the STPs. 

For A IN cases, the evaluation is more complicated since the network becomes hierarchical with parent- 
child relationships formed among the STPs organized by the routing to each specific service. Therefore, 
node cnncality becomes a function of not only the number and traffic from directly connected SSPs but 
also the number of SSPs indirectly connected that also gain access to the AJN service through the STP. 

Following the criticality evaluation, certain inherent vulnerability attributes are also evaluated, such as. 

• whether a node is owned or operated by a non-GTE entity is evaluated has the vulnerability increased 
by some measure. The ranking is applied by company. 

• whether the node is occupied by personnel and by how many (physical control) 

• how many backup nodes are available for auto rerouting. 



4.1.2 Link Evaluation 

The overall evaluation of the links is in effort to assess the inherent vulnerability to inserting messages onto 
the links to gain access to the critical nodes. However, the links are also evaluated on the cnncality 
attributes related to traffic load and by service. Therefore, the user service rankings also influence the link 
vulnerability. This functional capacity ranking is used throughout the evaluarion to modify the other 
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inherent vulnerab.lity attr.bute scores. At the end of the inherent link vulnerability analysis the links are 
modified one last time by the number of hops the link is from the cr.t.cal node The concept being that the 
greater number of hops from the target the less likely the inserted message will reach the intended target. 

The majority of the link attributes relate to inherent vulnerabilit.es of the links to SS7 message insertions 
aimed at affecting the critical nodes. Some examples are listed below: 

• physical media addresses the concept of a physical tap into a link and the relative accessibility of 
coax vice fiber. 1 

• whether the transmission facilities axe operated by a non-GTE entity is evaluated has the vulnerabtlirv 
increased by some measure. The ranking is applied by company, since some are more trusted than ' 
others. 

• amount message traffic originating external to the GTE network and therefore conung from potentially 
unknown sources. y 

• whether STP screening is invoked and the robustness of the screening logic 



4.2 Interfaces 

The context diagram, shown in Figure 4^», identifies the multiple IPCs needed by this subsystem The 
following subsections address these interfaces. 




Network 
Topology ' 



Network 

Topology 

Database 



Figure 4-4 - Vulnerability Analyzer Context Diagram 

4.2.1 User Interface 

The User Interface is the mechanism used for control and receive analysis results for display. 
4.2.1.1 Control and configuration 

In response to a control message from the GUI subsystem, the Vulnerability Analyzer accepts the 
following information from the GUI message queue for configuranon and control: 

a) START operation 

b) STOP operation 

c) PAUSE operation 
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d) Send Status/Statistic data 

e) Threshold and parameter values for algorithms 
4.2.1.2 Analysis Results 

Upon completion of the vulnerability analysis, the textual result* fil,. ic a;*~i a . l 

window. The POTS case lists the critical „Us> folded byte most vu t ? f ^ ' 

A IN case also mdicates the Most Crirical SCP vulnerable l.rucs to that node. The 

4.2.2 Network Topology Database 

The Network Topology Database provides the Vulnerability Analvzer aiam-ith™ ^ru .u 
relevant infrastructure data of the SS7 network. In addition"^ Xog 8 ^^epu^bvT'^ 
Detector, the Vulnerability Ana.yzer retires many additional ^^£d??^ST 

Routing in the GTE network for local STPs to regional STPs chano« a~s-~a- l ~ 

accessed . Th.s data had to be derived from dr.^f^S^^?" 8 r ^ ^ ^ 

and database algonthms to denve the proper lLZte S ' Sy " d mM analvsis 

5. Network Topology Database 

The Network Topology Database is the persistent storaee for the OTP cc-7 ^ r 

5.1 Concept of Execution 

In response to a client process, the database nrovides the m M ne fi,*» ~<-j . 

^ 6y < hm > . ^ * ;~ ttog 

5.1. 1 Interfaces 

The context diagram, shown in Figure 5-5. identifies the multiple tnterfaces used by this subsystem The 
following subsections address these interfaces. suosysiem. me 
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Figure 5-5 - Network Topology Database Domain Diagram 



5-1.1.1 GUI/Intrusion Detector 

The GUI and the Intrusion Detector will use the same information set from the database The GUI extracts 
the information needed to construct the operator's view of the local SS7 network, used to display the real 
nme conclusions of the Intrusion Detector. The Intrusion Detector uses the imk-node relationships to 
accomplish its algorithms (e.g., determine nearest neighbor, etc.). 

5. 1 . 1 .2 Vulnerability Analyzer 

The Vulnerability Analyzer requires a different information set from the of the Intrusion Detector It's 
requirements include not only link-node relationships, but also, link media type, mode supplier SS7 
services provided and so on. KK 
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1. Scope 

1.1 System Overview 

The System Network and Signal Infrastructure Vulnerability Analysis and Intrusion Detection System 
(hereafter referred to as the system) is a software application capable of provid.ng real-time protection to the 
U.S. telecommunications Signaling System No. 7 (SS7) infrastructure. 

The goal of the system is to perform the following: 

a) Determine the vulnerability of the SS7 network based on its topology and identify the 
network elements most vulnerable to intrusion. 

b) Detect intrusions to SS7 links being monitored. 

c) Provide a User Interface for operator control and status display in support of the above 
processes. 

The system uses a Sun Microsystems s SPARC-20 platform, running the Solaris 2.5 operating system. 

1.2 Document Overview 

This Software Users Manual (SUM) describes the procedures requtred for ustng the System protorvoe This 
system software includes two (2) independent tools: 

a) Intrusion Detector (including SS7 Monitoring, User Interface, and Anomaly Detecrion 
processes) 

b) Vulnerability Analyzer (User Interface, and Vulnerability Analysis processes) 

2. References 

The documents identified below provide background information and are incorporated herein by reference. 
DOCUMENT No. TITLE 

[ 1 ] ISO 900 1 International Organization of Standards 900 1 

[2] ANSI Tt. 1 1 1-1996 Signaling System Number 7, Message Transfer Part (MTP), 

American National Standards Institute Inc., 1996 

[3] ANSI Tl. 112-1996 Signaling System Number 7, Signaling Connection Control Part 

(SCCP), American National Standards Institute Inc., 1996 

[4] ANSI Tl. 1 13-1995 Signaling System Number 7, Integrated Serv.ces Digital Network 

User Part (ISDN), American National Standards Institute Inc 
1995 



3. (U) System Requirements 

This section describes the workstation 1 s configuration and system requirements necessary for the Sysi 
prototype. These requirements are shown below: 



Table 3-1 - System Requirements 



Name 


Description 


PLATFORM 




Operating System 


Solaris Version 2.5 1 
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Name 


Description 


PLATFORM 






System RAM 


64Meg or greater 


COTS Software 






Sybase Server 


Version 10.02 




Sybase Open 
Client 


Version 1 1.1 




ICS OSF/Motif 


Version 1.2.4 









4. System Installation and Environment Setup 

This section describes the installation and environment setup procedures necessary to get started with the 
applicanon. The following steps are required to run the system: 

a) Modifv the environment by adding the following lines to your .cshrc file. After modificanon. 
perform the required source .cshrc to implement these changes. 

i) setenv SYSTEMHOME pathname, where pathname defines the path of the 
System home directory. 

ii) setenv INTR_CONFIG S(SYSTEMHOME)/config, where 
S(SYSTEMHOME)/config defines the path of the System configuration sub- 
directory. 

iii) setenv XENVIRONMENT SrNTR_C0N7IG/gui.res. where 
$rNTR_CONFIG/gui.res defines the configuration file used for the X window 
environment 

iv) setenv MOTIFHOME /opt/Motifl24/usr, where pathname defines the path of the 
Motif compile-time libraries directory. 

v) setenv SYBASE pathname, where pathname defines the path of the Sybase 
database utilities (/cot&'sybase) 

vi) setenv DSQUERY SYSTEM 

vii) setenv LD_LEBRARY_PATH 

${LD_LIBRARY_PATH} :$MOTIFHOME'lib/X 1 1 :/usr/lib/Xl 1 :.usr/lang/lib.. usr li 
b:SOPE^rVv^rfflOME/Ub::SOPE^n^^NHOME/^ib:/us^/lib:$MOTIFHOM 11: 

usr/dt/lib 

viii) setenv PATH S{PATH>:SSYBASE/bin 

b) INSTALLATION: Move to this directory and extract TAR format tape: 

a) mkdir pathname, where pathname defines the path of the System home 
directory (as defined by SYSTEMHOME). 

b) cd SSYSTEMHOME. to move to this directory for installanon. 

c) tar xvf /dev/rmt/Q. to extract the tar file to the current directory. 

5. (U) Intrusion Detector Execution Procedure 

This section describes the information and instructions necessary for user interaction with the system Intrusion 
Detector. It gives the step-by-step procedures for executing the software and identifies the options available to 
the user. 



SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 



PCT/US99/17408 



APPENDIX B 
SOFTWARE USER'S MANUAL 

5.1 Initialization and Startup 

This section describes the initialization and startup procedures necessary to execute the software. To launch the 
Intrusion Detector executable, type IntrusionDetector on the command line of your UNIX shell. Upon startup of 
the System's Intrusion Detector application, the following events are performed: 

a) The required environment variables are retrieved from the system. These variables are 
defined in section 4. 

b) The application retrieves its default configuration from the startup initialization file 
"init config.intr". This file is stored in the directory SYSTEMHOME/config. 

Once the initialization of the application has completed, its GUI is displayed and ready for user interaction. The 
user must configure the tool, via the menu options or loading a previously saved configuration file. 

5.2 User Inputs and Control 

The following sections describe the user inputs and control for the system software. On-line help is provided 
within the application via the Help option. The user's primary control is in the form of a Graphical User 
Interface (GUI) shown in Figure 5-1. The GUI is provided to service the following operator control. 
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Figure 5-t- Top-Level GUI Environment 



5.2.1 File Management 

The application provides the capability to save and retrieve both configuration and output log files via the GUI. 
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5.2.2 Threshold Management 

The application provides the capability to view and modify all adjustable parameters required by the intrusion 
detection algorithms for maximum flexibility and expansion. The following list describes each of these GUI 
adjustable parameters. 



Table 5-1 - Intrusion Detection Adjustable Parameters 



Threshold Name 


Description 


Max Number of Changeovers 


The threshold for number of MTPCHANGEOVER messages per a 
predefined time period. 


Max Number of Emergency 
Changeovers 


The threshold for number of MTP EMERGENCY CHANGEOVER 
messages per a predefined time period. 


Max Number of Node Transfer 
Prohibit 


The threshold for number of MTP Node TRANSFER PROHIBIT 
messages per a predefined time period. 


Max Number of Cluster 
Transfer Prohibit 


The threshold for number of MTP Cluster TRANSFER PROHIBIT 
messages per a predefined time period. 


Max Number of Node Transfer 
Restrict 


The threshold for number of MTP Node TRANSFER RESTRICT 
messages per a predefined time period. 


Max Number of Cluster 
Transfer Restrict 


The threshold for number of MTP Ouster TRANSFER RESTRICT 
messages per a predefined rime period. 


Max Number of Node Transfer 
Control 


The threshold for number of MTP Node TRANSFER CONTROL 
messages per a predefined time period. 


Max Number of Cluster 
Transfer Control 


The threshold for number of MTP Ouster TRANSFER CONTROL 
messages per a predefined time period. 


Max Number of Link Inhibits 


The threshold for number of MTP LINK INHIBIT messages per a 
predefined time period. 


Max Number of Partem SLC 


The threshold for number of consecutive SLCs inhibited, prohibited, 
restricted, or reset 


Max Number of Node Releases 


The threshold for number of ISUP Node RELEASE messages per a 
predefined time period. 


Max Number of Group Releases 


The threshold for number of ISUP GROUP RELEASE messages per a 
predefined time period. 


Max Number of Node Resets 


The threshold for number of ISUP Node RESET messages per a 
predefined time period. 


Max Number of Group Resets 


The threshold for number of ISUP GROUP RESET messages per a 
predefined rime period. 


Max Number of Node Blocks 


the tnresnoia tor numDcr oi iaur i^ouc dlu^-iv unsaagu u 
predefined time period. 


Max Number of Group Blocks 


The threshold for number of ISUP GROUP BLOCK messages per a 
predefined time period. 


Max Number of Unequipped 
Circuits 


The threshold for number of ISUP ISUP UNEQUIPPED CIRCUIT 
messages per a predefined time period. 


Max Number of Circuits Query 


The threshold for number of ISUP ISUP CIRCUIT QUERIES messages 
per a predefined time period. 


Max Number of Pattern CIC 


The threshold for number of consecunve CICs released, blocked, reset 
or unequipped. 


Max Number of Signaling 
Route Set Test Anomalies 


The threshold for number of ISUP SIGNALING ROUTE SET TEST 
anomalies per a predefined time period. 


Max Number of Signaling 
Route Set Congestion Test 
Anomalies 


The threshold for number of ISUP SIGNALING ROUTE SET 
CONGESTION TEST anomalies per a predefined tune period. 
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Threshold Name 


Description 







5.2.3 View Control 

The application provides the capability to enter monitor point(s) to which the protocol analyzer is connected. 
This data is used to define the local topology view displayed to the user. The monitor points are entered using 
the "View | Monitor Point Selection" menu option provided by the GUI. 

5.2.4 Start/Stop 

The application provides the capability to start and stop processing of the application using the "Control Start" 
and the "Control I Stop" GUI menu options, respectively. 

In order to start execurion, valid monitoring points must be loaded, either from the GUI or by loading a 
previously stored configuration file. An error is displayed if this condition is not met. The generation and 
display of the local topology view immediately follows. 

5.2.5 Termination 

The applicanon provides the capability to terminate execunon of the applicanon using the "File : Exit" menu 
option provided by the GUI. 

5.3 System Inputs 

The following sections describe the system inputs to the system and are required for the proper operation of the 
applicanon. 

5.3.1 Protocol Analyzer 

The protocol analyzer selected for the system is the INET Turbo-7 protocol analyzer. Up to four (4) SS7 links 
can be monitored at one time by this device. The message format, shown in Table 5-2, is expected from the 
analyzer via the TCP/IP port. 

Table 5-2 - INET MSU Record Format 



Field Name 


Number of 
Bytes 


Description 








Times tamp 


4 


GMT 


Tick 


2 


millisecond resolution 


Port Number 


1 


Analyzer's Port Number used for monitoring 
(Spin ode Link Number) 


Length 


2 


Length of the remainder of this record (to the end) 


MSU Body 


X 


Forwarded message 









5.3.2 Input MSU Test File 

This section describes the MSU formats used by the input test file. The test file injects the test MSU into the 
real-rime path for the purpose of diagnostics. Table 5-3 details the different formats expected for the different 
SS7 MSU types. 



Table 5-3 - Input Test File MSU Formats 


MSU 
Type 


MSU Function 


MSU Data Fields 


Comments 
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MSU 
Type 
MTP 


MSU Function 


MSU Data Fields 


Comments 








Monitored Port Number 


rNET Port number assigned to desired link 






Direction 


Direcrional indication (0/1 = DTE/DCE) 






delta Time Stamp 


Time delay of MSU insertion 






MSU Type 


Indicates whether Mlr*(0) or ISUP (5) 






MSU function 


MSU function (See reference [2]) 






OPC 


Origination Point Code of MSU 






DPC 


Designation Point Code of MSU 






SLC 


Signal Link Code of MSU 






destination (for TFP, 
TFR, TFA only) 


Destination Point Code of Transfer Control MSL's 




ISUP 








Address Complete 
Answer Message 
Call Progress 
Unequipped Circuit 
Release Complete 
CIC Reset 
CIC UnBlock 
CIC UnBlock Ack 
CIC Block 
CIC Block Ack 


Monitored Port Number 


INET Port number assigned to desired link 




Direction 


Directional indication (0/1 = DTE/DCE) 


delta Time Stamp 


Time delay of MSU insertion 




MSU Type 


Indicates whether MTP (0) or ISUP (5) 




MSU function 


MSU function (See reference [4]) 


OPC 


Origination Point Code of MSU 


DPC 


Designation Point Code of MSU 


CIC 


Circuit Identification Code 










Release Requested 


Monitored Port Number 


INET Port number assigned to desired link 


Direction 


Directional indication (0/1 = DTE/DCE) 


delta Time Stamp' 


Time delay of MSU insertion 


MSU Type 


Indicates whether MTP (0) or ISUP (5) 


MSU function 


MSU function (See reference [4]) 


OPC 


Origination Point Code of MSU 


DPC 


Designation Point Code of MSU 


CIC 


Circuit Identification Code 


Cause Code 


Cause Code of RELEASE MSU 


Initial Address 


Monitored Port Number 


INET Port number assigned to desired link 


Direction 


Direcrional indication (0/1 = DTE/DCE) 


delta Time Stamp 


Time delay of MSU insertion 




MSU Type 


Indicates whether MTP (0) or ISUP (5) 




MSU function 


MSU function (See reference [4]) 




OPC 


Origination Point Code of MSU 




DPC 


Designation Point Code of MSU 




CIC 


Circuit Identification Code 




Called Area Code 






Called Number 






Calling Area Code 






Calling Number 






Group Reset 


Monitored Port Number 


INET Pott number assigned to desired link 


Group Block 


Direction 


Direcrional indication (0/1 = DTE/DCE) 


Group Block Ack 


delta Time Stamp 


Time delay of MSU insertion 


Group UnBlock 


MSU Type 


Indicates whether MTP (0) or ISUP (5) 


Group UnBlock Ack 


MSU function 


MSU function (See reference [4]) 
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occurrence of an anomaly, ihe event and background informanon ,s logged and stored in the intrus.on 
Detection log. 



Table 5-4 - Output Anomaly Messages 



Anomaly 
Code 


Description of Anomaly 


SS7 Protocol 
Effected 


100 


LINK NEAREST NEIGHBOR FAILURE - A SS7 MTP message was rece.ved where 
the OPC and DPC did not correspond to the required link 


MTP 


101 


' EXCESSIVE CHANGEOVER ■ The occurrences of CHANGEOVER messages to a ' 
link exceeded the operator's adjustable threshold. 


MTP 


102 


EXCESSIVE EMERGENCY CHANGEOVER - The occurrences of EMERGENCY 

CHANGEOVER messages to a link exceeded the operator s adjustable threshold 


.VI I r 


103 


CHANGEOVER REQUEST TIMEOUT - A timeout has been detected after a 

CHANGEOVER message was detected on a monitored link. NO corresponding 
acknowledgment was detected. 


M 1 r 


104 


EXCESSIVE NODE TRANSFER PROHIBITS - The occurrences of node TRANSFER 
PROHIBIT messages to a link exceeded the operator's adjustable threshold 


i V <TD 

j \l J r 

i 


105 


EXCESSIVE CLUSTER TRANSFER PROHIBITS - Ihe occurrences of cluster 

TRANSFER PROHIBIT messages to a link exceeded the operator s adjustable 
threshold. 


WTD 

• M 1 r 

i 
| 


106 


EXCESSIVE NODE TRANSFER RESTRICTS - The occurrences of node TRANSFER 
RESTRICT messages to a link exceeded the operator s adjustable threshold 


i MTP 

i 


107 


EXCESSIVE CLUSTER TRANSFER RESTRICTS - Ihe occurrences of cl uster 

TRANSFER RESTRICT messages to a link exceeded the operator's adjustable 
threshold. 


MTP 


108 


EXCESSIVE NODE TRANSFER CONTROL - The occurrences of node TRANSFER J 
CONTROL messages to a link exceeded the operator's adjustable threshold 


MTP 


109 


EXCESSIVE CLUSTER TRANSFER CONTROL - The occurrences of cluster 

TRANSFER CONTROL messages to a link exceeded the operator's adjustable 
threshold. 


MTP 


110 


EXCESSTv E LINK INHIBITS - The occurrences of node LINK INHIBIT messages to 
a link exceeded the operator's adjustable threshold. [ 


MTP 


1 1 1 


INVALID SLC INHIBIT PATTERN ■ The partem of inhibit SLCs observed on a link j 
was not random and exceeded the operator's adjustable threshold. 1 


MTP 


1 12 


INVALID CHANGEOVER - A CHANGhO V hR message was rece.ved while the sameT~ 

monitored link wis already in a CHANGEOVER state 1 


1 13 


INVALID CHANGEOVER ACKNOWLEDGE - A CHANGEOVER message was " 

received wuh NO corresponding CHANGEOVER message detected on the same 
monitored Imlr 


MTP 


1 14 


INVALID DIRECTION ON CHANGEOVER ACKNOWLEDGE - A CHANGEOVER 
ACKNOWLEDGE message was received from the wrong direction relative to the last 
corresponding MSU message. 


MTP 


115 


INVALID EMERGENCY CHANGEOVER - An EMERGENCY CHANGEOVER " 

message was received while the same monitored link was already in a CHANGEOVER 
state. 




1 16 
IP 


INVALID EMERGENCY CHANGEOVER ACKNOWLEDGE - An EMERGENCY ^~ 

CHANGEOVER message was received with NO corresponding CHANGEOVER 
message detected on the same monitored link. 

INVALID DIRECTION ON EMERGENCY CHANGEOVER ACKNOWLEDGE ■ \u 


MTP 
MTP 



35 



SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 



PCT/US99/17408 



APPENDIX B 
SOFTWARE USER'S MANUAL 



1 Aaomal) 
1 Code 


i ~~ — — _____ __ 

Description of Anomaly 


SS7 Protocol 
t. fleeted 




t.MfcRGENCY CHANGEOVER ACKNOWLEDGE message was received from the " 
wrong direction relative to the last corresponding MSU m«u« 




118 


INVALID OPC ON IRANSFER PROHIBIT- A TRANSFER PROHIBIT message wis 
rece.ved ongtnanng from a pom. code and did not correspond ,„ _ STP !I 


MTP 


119 


'^f * mHm T- A TRANSFER PROHIBITS . gc was 
receivedwith NO corresponding CHANGEOVER or LINK INHIBIT detected on thV 
monitored link to the destination point code 


MTP 


120 

TTi 


INVALID REMO , t I KANSFER PROH1BI 1 - A TRANSFER PROHIBIT message 
was rece.ved wtth NO corresponding TRANSFER PROHIBIT detected from a 
connecting STP. 

' [NVALID OPC ON I KANSFER RESTRICT . A TRANSFER RES ITUCT message ~ 
was received ongtnanng from a point code and did not corresoond ,„ _ <tp p „. m * nrir 


MTP 
MTP 


122 


INVALID LOCAL TRANSFER RESTRICT - A TRANSFEREES 1RICT mes^! ' 
received with NO corresponding CHANGEOVER or LINK INHIBIT detected on the 
monitored link to the desnnanon point code 


MTP 


123 


INVALID REMOTE IRANSFER RESTRICT - A TRANSFER RESTRICT message " 
was received with NO corresponding TRANSFER PROHIBIT detert-rf f™-. , 
connecting STP. rKUHlBU detected from a 


i MTP 

1 


124 


INVALID - SIGNALING ROUTE SET IfcST- A SIGNALING ROUTE SET TEST 

»rc4l^ aS reCC,Ved WIth N ° corres P° n ding TRANSFER PROHIBIT or TRANSFER 
RESTRICT detected on the same monitored link 


MTP 


125 
I 126 


INVALID NUMBER OF SIGNALING ROUTE SET TESTS PROHIBIT to TFA - Less " 
than two (2) SIGNALING ROUTE SET TEST PROHIBIT messages were reeved 
before a corresponding TRANSFER ALLOW message was H-tr*-,~i .l 
monitored link. «««age was detected on the same 


MTP 




INVALID NUMBtR OF SIGNALING ROUTE SET TESTS RESTRICT to TFA ' 

Less than two (2) SIGNALING ROUTE SET TEST RESTRICT m „<„<,~ ' 

— 1 » *--> * "-w i _v_^_ 1 messages were 

received before a corresponding TRANSFER ALLOW message was detected on the 

same monitored link. 


MTP 


12? 
I 128 


INVALID TRANSFER ALLOWED . A TRANSFER ALLOWED message was L 

received w,tb NO corresponding SIGNALING ROUTE SET TEST message detected 
on the same monitored link. 


MTP 




IN-VALID DIRECTION ON TRANSFER ALLOWED - A TRANSFER ALLOWED u 

m""S rCCeiVed fr ° m ±C Wr0Dg dlreCn ° D reUDVe 10 laSt «»»*P««lMg MSU 


MTP 


129 


INVALID OPC ON IRANSh ER CONTROL - A 1 KANSFER CONTROL message ^ 

was received originating from a point code and d.rf nm r n ~,^ nf1 m - STT > nrMnr * , ,, 


MTP 


130 


SISSSS zsr_r_r - N0 -— — ™"«« 


MTP 


131 


INVALID NUMBER OF SICNai rx;r: pnr tt cf~- -r-r-f-f — ; --———-——_—___ 

,-,~? . „ jiuin^luno kuo 1 1 SET TtS 1 S- Less than two (21 

TRANSFER ALLOW message was detected on the same mon.tnr-ri lint 


MTP 


132 


INVALID LINK INHIBIT - A LINK INHIBIT message was detected on , monitored ' 
ink that was tagged NOT AVAILABLE or LINK rNHmrr ... m MPI Fp M 


MTP 


J 133 
1 134 


NVALID NUMBER OF LINK INHIBITS - Greater than two (2) LINK INHIBrT L 

nessages were detected on the same monitored link 

-INK INHIBIT REQUEST TIMEOUT - A T14 timeout has been detected ,fW M 1 


MTP 
MTP 
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Anomaly 
Code 


Description of Anomaly 


SS7 Protocol 
Effected 










fNHIBIT message wis detected on a monitored link. NO corresponding 
acknowledgment or denial was detected. 




135 


INVALID LINK INHIBIT ACKNOWLEDGE - A LINK INHIBIT ACKNOWLEDGE 
message was received with NO corresponding LINK INHIBIT message detected on the 
same monitored link. 


MTP 


136 


LINK INHIBIT ACKNOWLEDGE TIMEOUT - A MAX(T20,T21 ) omeout has been 
detected after a LINK INHIBIT ACKNOWLEDGE message was detected on a 
monitored link. NO corresponding TEST or UN INHIBIT was detected. 


MTP 


137 


INVALID LINK LOCAL TEST - A LINK LOCAL TEST message was received with 
NO corresponding LINK INHIBIT ACKNOWLEDGE message detected on the same 
monitored link. 


MTP 


138 


INVALID NUMBER OF LINK LOCAL TESTS- Less than two (2) consecutive LINK 
LOCAL TEST messages were received before a corresponding LINK UNINHIBIT or 
LINK FORCED UNINHIBIT message was detected on the same monitored link. 


MTP 


139 


LINK LOCAL TEST TIMEOUT - A T20 omeout has been detected after a LINK 
LOCAL TEST message was detected on a monitored link. NO corresponding LINK 
UNINHIBIT or LINK FORCED UNINHTBIT message was detected. 


MTP 


140 


INVALID LINK REMOTE TEST - A LINK REMOTE TEST message was received 
with NO corresponding LINK INHIBIT ACKNOWLEDGE message detected on the 
same monitored link. 


.MTP 


141 


INVALID NUMBER OF LINK REMOTE TESTS- Less than two (2) consecutive 
LINK REMOTE TEST messages were received before a corresponding LINK 
UNINHIBIT or LINK FORCED UNINHIBIT message was detected on the same 
monitored link. 


MTP 


142 


LINK REMOTE TEST TIMEOUT - A T2 1 timeout has been detected after a LINK 
REMOTE TEST message was detected on a monitored link. NO corresponding LINK 
UNTNHEBiT or LINK FORCED UNINHTBIT message was detected- | 


MTP 


143 


RESERVED j 


MTP 




1 


200 


EXCESSIVE RELEASES - The occurrences of CIC RELEASE messages exceeded the j 
operator's adjustable threshold. I 


ISUP 


201 


EXCESSIVE GROUP RESETS - The occurrences of CIC GROUP RESET messages 
exceeded the operator's adjustable threshold 1 


ISLT 


202 


EXCESSIVE NODE RESETS - The occurrences of CIC NODE RESET messages 
exceeded the operator's adjustable threshold i 


ISUP 


203 


EXCESSIVE GROUP BLOCKS - The occurrences of CIC GROUP BLOCK messages i 
exceeded the operator's adjustable threshold. ( 


ISLT 


204 


EXCESSIVE NODE BLOCKS - The occurrences of CIC NODE BLOCK messages 
exceeded the operator's adjustable threshold. 


ISUP 


205 


EXCESS IVE UNEQUIPPED CIRCUITS - The occurrences of CIC UNEQUIPPED • 
CIRCUIT messages exceeded the operator's adjustable threshold. | 


ISLT 


206 


EXCESS IVE CIRCUIT QUERIES - The occurrences of CIC CIRCUIT QUERY j 
messages exceeded the operator' s adjustable threshold. | 


ISLT 


207 


INVALID CIC RELEASE PA 1 I bRN - The pattern of released CICs observed was not 
random and exceeded the operator's adjustable threshold. 


ISLT 


208 


INVALID CIC BLOCK PA lTtRN - The partem of blocked CICs observed was not j 
random and exceeded the operator's adjustable threshold. | 


ISLT 


209 


INVALID CIC RESET PA l'l hRN - The panern of reset CICs observed was not i 


ISLT 
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Anomaly 




SS7 Protocol 


Code 


Description of Anomaly 


Effected 


i 




1 random and exceeded the operator's adjustable threshold. 




210 


INVALID CIC UNEQUIPPED PATTERN - The partem of unequipped CICs observed 
was not random and exceeded the operator's adjustable threshold. 


ISUP 


211 


[NVaILD ADDRESS COMPLETE - An ADDRESS COMPLETE message was 
received with NO corresponding INITIAL ADDRESS message detected on the same or 
mated monitored link. 


ISUP 


212 


INVALID POINT CODE - A SS7 M^U message was received with an invalid point 
code (OPC or DPQ. 


; ISUP 
1 


213 


TRUNK NEAREST NEIGHBOR FAILURE • A SS7 ISUP message was received 
where the OPC and DPC did not correspond to nodes with a common crunk. 


ISLT 


2U 


INVALID INITIATED CALL - An INITIAL ADDRESS message was received for a 
CIC alreadv allocated. This MSU has been ignored by the network. 


ISUP 


2!5 


INVALID RELEASE - A RELEASE message was received with NO corresponding 
INITIAL ADDRESS or ADDRESS COMPLETE message detected in the opposite 
direction on the same or mated monitored link. 


ISLT 


216 


ABNORMAL CAUSE CODE ON RELEASE - A valid RELEASE message was 
received with an abnormal CAUSE CODE. 


ISUP 


:r 


RELEASE TIMEOUT - A five (5) minute timeout has been detected after a RELEASE 
messaee wu detected on a mo tutored link NO corresoondino R FI FA ^F fOMPT FTF 
message detected in the opposite direction on the same or mated monitored link. 


ISLT 


218 


INVALID RELEASE COMPLETE - A RELEASE COMPLETF w« received u/irh a 
corresponding BLOCK message detected on the same or mated monitored link, 
however, the direction of the RLC message, relanve to the corresponding BLOCK 
messase. was incorrect. 


ISLT 


219 


INVALID RELEASE COMPLETE - A RELEASE COMPLETE message was received 
with NO corresponding RELEASE. RESET or BLOCK message detected on the same 
or mated monitored link. 


ISLT 


220 


INVALID D ERECTION RELEASE COMPLETE - A RELEASE COMPLETE was 
received from the wrong direction relative to the last corresponding MSU message. 


ISUP 


221 


INSERTED RESET - A RELEASE COMPLETE message was correlated to a 
previously detected BLOCK message in the same direction on the same or mated 
monitored link. This indicates a RESET message inserted at OPC. 


ISLT 




INVALID GROUP RESET - A two (2) consecutive GROUP RESET messages were 1 
not in the same direction on the same or mated monitored link. | 


ISLT 


223 


GROUP RESET TIMEOUT - A five (5) second timeout for the second of two GROUP 
RESET messages has occurred. 


ISLT 


224 


INVALID RESET - A RESET message was received and was correlated to a 
previously detected RELEASE COMPLETE message in the opposite direction on the 
same or mated monitored link. 


ISLT 


225 


RESET TIMEOUT - A fifteen (15) second timeout has occurred between a RESET 
message and its corresponding UNEQUIPPED CIRCUIT message on the same or 
mated monitored link. 


ISUP 


226 


INVALID GROUP BLOCK - A two (2) consecunve GROUP BLOCK messages were 
not in the same direction on the same or mated monitored link. 


ISUP 


227 


GROUP BLOCK TIMEOUT - A five (5) second timeout for the second of two (2) 
GROUP BLOCK messages has occurred. 


ISUP 


228 


INVALID BLOCK - A BLOCK message was received and was correlated to a 
previously detected UNBLOCK ACKNOWLEDGE message in the opposite direcnoo 


ISLT 
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Anomaly 
Code 


Description of Anomaly 


SS7 Protocol 
Effected 










on the same or mated monitored link within a fifteen ( 1 5) second tune internal. 




229 


INVALID BLOCK ACKNOWLEDGE - A BLOCK ACKNOWLEDGE message was 
received with NO corresponding BLOCK message detected in the opposite direction on 
the same or mated monitored link. 


ISUP 


230 


INVALID DIRECTION BLOCK ACKNOWLEDGE - A BLOCK ACKNOWLEDGE 
was received from the wrong direction relative to the last corresponding MSU message. 


ISUP 


23 1 


BLOCK. ACKNOWLtUOt 1 IMtOU I - A live (5) minute timeout has been detected 
after a BLOCK ACKNOWLEDGE message was received on a the same or mated 
monitored link. NO corresponding UNBLOCK message was detected. 


ISUP 


232 


INVALID UNBLOCK • A UNBLOCK message was received with NO corresponding 
BLOCK ACKNOWLEDGE message detected in the opposite direction on the same or 
mated monitored link. 


ISUP 


233 


EARLY UNBLOCK - A UNBLOCK message was received and was correlated to a 
previously detected BLOCK ACKNOWLEDGE message in the opposite direction on 
the same or mated monitored link within a fifteen (IS) second time internal. 


[SUP 


234 


INVALID DIRECTION FOR UNBLOCK - A UNBLOCK was received from the 
wrong direction relative to the last corresponding MSU message. 


ISUP 


235 


INVALID UNBLOCK ACKNOWLEDGE - A UNBLOCK ACKNOWLEDGE 
message was received with NO corresponding UNBLOCK message detected in the 
opposite direction on the same or mated monitored link. 


ISUP 


236 


INVALID DIRECTION FOR UNBLOCK ACKNOWLEDGE - A UNBLOCK 
ACKNOWLEDGE was received from the wrong direction relative to the last 
corresponding MSU message. 


ISUP 


237 


INVALID UNEQUIPPED CIRCUIT - An UNEQUIPPED CIRCUIT message was 
received with NO corresponding RELEASE, RESET. GROUP RESET, GROUP 

R I Of*K or RI C\C^1C mescAffe detected in th^ nnnncit** Htrr*rtinn An rK* «« m > nr 

monitored link. 


ISUP 


238 


INVALID DIRECTION FOR UNEQUIPPED CIRCUIT - An UNEQUIPPED 
CIRCUIT message was received from the wrong direcnon relative to the last 
corresponding MSU message. 


ISUP 


239 


INVALID CIRCUIT QUERY- A CIRCUIT QUERY message was received and was 
correlated to a previously detected RELEASE COMPLETE message in the opposite 
direcnon on the same or mated monitored link. 


ISUP 


240 - 299 


Reserved 





5.4.3 (U) Operational Error and Warning Messages 

This section identifies all error messages output by the system, the meaning of each cnor message, and the 
action (o be taken when each message appears. These messages are displayed to the user via the GUI. In 
addition, faults are logged by the each individual process into its corresponding flat file. Each fault log can be 
enabled/disabled by the system configuration file previously loaded. 



Table 5-5 - Operational Error and Warning Messages 



Error 
Code 


Description of Error/Warning 


Action Required 








1000 


ERROR: CHILD CREATION FAULT DETECTED - There was a 


Verify the presence of the 



39 



SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 



PCT/US99/17408 



APPENDIX B 
_ SOFTWARE USER'S MANUAL 



Error 
Code 


Description of Error/Warning 


Action Required 










failure during the creation of a child process (Process Manager). 


corresponding executable and 
restart the intrusion n»t»rrAr 


1001 


ERROR: EXCESSIVE ANOMALIES DETECTED • The number of 
anomalies have exceeded the system limit (Intrusion Detccnon 
Process). 


Adjust thresholds, exit and restart 

Ulfc UlUUOlUil LSClCClUI lOOI. 


1002 


ERROR: INVALID MONITOR POINT LOADED - A monitor 
point's point code or link ID is invalid (Display Management). 


Enter valid monitor point as 
oromnted bv the Ci\ "I 

U1VIIU/IVU J Ulv \J | . 


1003 


ERROR: DUPLICATE MONITOR POrNT LOADED - The monitor 
point entry entered already exists. 


Enter valid monitor point as 
prompted by the GUI. 


I0O4 


ERROR: INVALID PORT NUMBER DETECTED - A port number 
was detected that does not correspond to an exisnng monitor point 
cntrv. MSU was ignored (Intrusion Detection Process). 


cjiiici vdua port numDcr as 
prompted by the GUI. 


1005 


ERROR: INVALID FILENAME - The filename entered was not 

found fDisnlav Management) 


Enter valid filename as prompted 

hv the CiI 'I 


1006 


ERROR: UNDEFINED ENVIRONMENT VARIABLE - An 
environment variable has not been defined » Aborting program (All 


Terminate program define 
environment variable and restart 

piOgldJTl. 


1007 


ERROR: UNEXPECTED CHILD PROCESS TERMINATION - An 

im^Yrwt ^ri tprrninarinn of a child nrntp^^ Knc pn H^r^ft^H — 

Aborting program (Display Management). 


Res tan program. 


1008 


ERROR: IPC SEND ERROR - Message Queue SEND Error detected 

— Ahnrtino nrnorsm f All nmcecscs) 




1009 


ERROR: IPC OPEN ERROR - Message Queue OPEN Error detected 
— Aborting program (AH processes). 




1010 


ERROR: COMM PORT OPEN FAILURE - The Communication 
Port failed during an open attempt (Data Collector Process). 


▼ tiny >ia.kci t-uiuicuon uer*ccn 
the protocol analyzer and the 
System workstanon. 


101 1 


ERROR: BAD TEST FILE DATA - Invalid data format within test 
input file specified (Data Collector Process). 


Verify test file name selected 

linn^r frtf* '*Tn«*if C«lM>nnn" . . 

uiiuci uic uipui ociecnon menu. 


1012 


ERROR: DATABASE FAILURE - Database communication 
problem. Unable to connect to database server -• Aborting program 
(All processes). 


Venfy database configuration. 


1013 to 
1099 


i\C5crvcu 










1100 


WARNING: TRANSFER PROHIBIT IS UNVERfflABLE - A 
i KArorcK rKwriioi l message was received tnat coulu not De 
verified due to the monitoring point set selection (Intrusion Detection 
Process). 


No Acnon Required. 


1101 


WARNING: TRANSFER RESTRICT IS UNVERfflABLE - A 
TRANSFER RESTRICT message was received that could not be 
verified due to the monitoring point set selection (Intrusion Detccnon 
Process). 


No Acnon Required. 


1102 


WARNING: TRANSFER CONTROL IS UNVERfflABLE - A 
TRANSFER CONTROL message was received that could not be 
verified due to the monitoring point set selection (Intrusion Detection 
Process). 


No Acnon Required. 


1103 


WARNING: MTP INTRUSION DETECTION ONLY - Due to the 


Enter new monitor points that 
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1105 



WARNING. PARTIAL CONFIGURA HON LOADED - An" 
■'n m |!! e ' e COnflgUration f,le »" (P.splay Management. 



WARNING. COMM PORT OPEN RETRY - No Commun.canor7 
Port connection - Retrying (Data Collector Process). 




monitor all links to a desired SSP 
for ISUP. 



Load complete configurat.on tile. 



Verify socket connection between 
the protocol analyzer and the 
System workstation 
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6. (U) Vulnerability Analyzer Execution Procedure 

This section describes the information and instructions necessary for user interaction with the System 
Vulnerability Analyzer. It gives the stcp-by-step procedures for executing the software and identifies the 
options available to the user. 

6.1 Initialization and Startup 

This section describes the initialization and startup procedures necessary to execute the software To launch the 
Vulnerability Analyzer executable, type VulnerabilityAnalysis on the command line of your UNIX shell Uoon 
startup of the System's Vulnerability Analyzer application, the following events are performed: ' 

a) The required env ironment variables arc retrieved from the system. These variables are 
defined in section 4. 



b) The application retrieves its default configuration from the startup initialization file 
•'init_config.vuln". This file is stored in the directory SYSTEMHOME/config. 

Once the initialization of the application has completed, its GUI is displayed and ready for user interaction 
The user must configure the tool, via the menu options or loading a previously saved configuration file. 

6.2 User Inputs and Control 

The following sections describe the user inputs and control for this application. On-line help is provided within 

,™ m P u° an0n VU He ' P ° ptl0n - ThC USCr ' S primary contro1 is m the fom > ° f * Graphical User Interface 
(GUI) shown in Figure 4.2. The GUI is provided to service the following operator control 
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Figure 6-t - Vulnerability Analysis Top Level GUI 

6.2.1 File Management 

The application provides the capability to save and retrieve both configuration and analysis result flies via the 
GUI under the File selection. 



6.2.1.1 File Save 

The Save selection allows the user to save the current analysis results to a user specified file name. Also the 
user mav select to save the current configuration to a user specified file name for later retrieval. 



6.2.1.2 File Retrieve 

The retrieve selection allows the user to retrieve an analysis results log or to retrieve an existing configuration 
file. When the Retrieve ; Configuration is selected, the File window appears. The user may then enter a filter 
selection and click on the Filter burton to narrow his selection, and click on a file name in the files section. The 
selected file is displayed under Selection and the user clicks on OK to load the file in memory. In order to view 
the loaded configuration file, the user must select Retrieve Analysis. Note that the file is not editable via the 
GUI. The parameters contained in the configuration file are described in Table 6- 1 

Table 6-1 - Vulnerability Configuration Parameters 
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Ranking Name 


Description 


POTS Service Rank 


Priority ranking for POTS service 


Physical Link Rank 


Priority rankings for the physical media types of fiber, microwave, 
satellite, and coax. 


Media Link Rank 


The physical media provider rankings for Git, A T&T. Sprint, MCI, 
Ameritech, Bell South, Southwestern Bell. Bell Atlantic, US West, Delta 
Communications, NTS Communications, PTI Communications, Norlite, 
and any others. 


Functional Link Rank 


Functional capacity rankings for the percent of urilizanon on the links 
and rankings based on the number of links in the linkset. 


Security Link Rank 


Rankings for the security characteristics of the link such as encrypnon. 
and the combination of point code screening (no point code screening, 
network only, network cluster, and network cluster member), with logic 
screening (no logic screening, message class, and message type). 


Media Access Modifier 


Multiplier applied to the media provider based on the link s physical 
media type of fiber, microwave, satellite, or coax. 


Services Multi Modifier 


Addend applied to the link score based on the number of services ranked 
at high, medium, and low rankings. High rank is from 8 to 10 inclusive, 
medium is from 4 to 7 inclusive, and low is from 1 to 3 inclusive. 


Funcnonal Capacity Modifier 


Functional capacity subtrahend based on the utilization rank and the 
number of links rank, functional capacity addend based on the percent of 
traffic on the link which is generated internal, functional capacity 
addend based on tie percent of traffic on the link which is generated 
external the funcnonal capacity subtrahend based on the score class and 
security monitoring, the security rank subtrahend based on the 
screening rank and security monitoring, and the service rank multiplier 
which is applied to the security rank. 


Functional Capacity Limit 


Functional capacity percent utilization lower and upper limits, the 
percent of traffic generated external lower and upper limits, and the 
threshold for the number of links in the linkset. 


High Security Media Combo 


Subtrahend applied to the link's physical access score when the link is 
classified as having nigh security, along with the various high, medium, 
and low combinations for functional services and funcnonal capacity. 


Medium Security Media Combo 


Subtrahend applied to the link's physical access score when the link is 
classified as having medium security, along with the various high, 
medium, and low combinations for functional services and functional 
capacity. 


Low Security Media Combo 


Subtrahend applied to the link's physical access score when the link is 
classified as having low security, along with the various high, medium, 
and low combinations for functional services and functional capacity. 


SSP Node Type Rank 


Defauit node ranking for three types of SSPs: tandem, end office, and 
TOPS 


Overall Node Limits 


Thresholds for the number of occupants located at the node 


Overall Node Modifier 


Node owner ranking tor Ci 1 h, A 1 & I , MCI, Spnnt, Bell Atlantic, Bell 
South Pacific Bell, Ameritech, US West, LCI, and any others; addend 
applied to the criticality score based on the node access as far as 
occupied, remote public, or remote private; and the amount of reduction 
of the criticality score based on whether a security observation exists. 


Correlation Modifier 


The amount to reduce the link vulnerability score based on the number 
of hops the link is from the critical node. 


Display Limit 


The maximum number of nodes at the highest crincaliry score which 
may be identified as the most critical node. The maximum number of 
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Ranking Name 


Description 




links displaying detailed link information to the operator. 


Network Area 


Analyzed network regional area defined by longitude upper and lower 
bounds, and latitude upper and lower bounds. 


Rank Assignment 


SSP point codes and their associated SSP priority ranking. 


Palletcl Ranking 


Services evaluated (POTS or SCP services). Priority rankings for the 
SCP services of E800CA. E800FW, CRS, INCONTACT, and LIDB 
CNAME. 


Fault Log Configuration 


Enabling or disabling of the fault log. 



6.2.2 Rankings Management 

The application provides the capability to view and modify the rankings of individual SSPs and services. Refer 
to Figure 4.2 to see the format of the windows. If the operator selects the SSP ranking then he must provide a 
SSP point code, and an integer ranking between one and ten inclusive. The SSP point code is of the format 
xxx-xxx-xxx. where x is an integer. If the user selects the services rankings then a Services window pops up 
with the default POTS service selected. If he changes the services selection to SCP Services, then he must 
supply an integer ranking between one and ten inclusive for each of the services identified in Table 6-2. By 
entering a high ranking for a service, the user is assigning a higher priority to the service for his analysis. 



Table 6-2 - Vulnerability Adjustable Rankings 



Service Ranking Name 


Description 


E800CA 


800 service homed to California 


E800FW 


800 service homed to Indiana 


CRS 


Customer Routing Service for business customers (call forwarding) 


INCONTACT 


Customer Routing Service for residential customers 


LIDB CNAME 


Line Information Data Base Caller Name (calling card data, collect & 
third party billing, presubscribed interexchange earner, foreign records, 
caller identification with names) 



6.2.3 Controls 

The applicanon provides the user with the capability to start and stop processing of the application using the 
"Control Start" and the "Control | Stop" GUI menu opnons, respecnvely. 

6.2.4 Termination 

The application provides the capability to terminate execution of the applicanon using the "File : Exit" menu 
opnon provided by the GUI (similar to the Intrusion Detection). 

6.3 System Inputs 

The following sections describe the system inputs to the system and are required for the proper operation of the 
application. 

6.3.1 Topology Database 

The topology database is the repository of information related to the configuration and the individual 
characteristics of each element of the GTE proprietary SS7 network. 

6.3.2 Help Files 

Several HELP flat files are required by the application in support of the HELP option within the GUI. These 
files must be installed at the path defined by the SYSTEMHELP environment variable (similar to the Intrusion 
Detector). The required help files are: 
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a) filejiclp • This is the Oat file containing the help text for the "File- menu options 

b) services_help - This is the flat Tile containing the help text for the "Rankings ; Services" 
menu option. 

c) vuln_monitor_help • This is the flat file containing the help text for the "Rankings : SSP" 
menu option. ' 

d) vulnerabiJity_help - This is the flat file contaming the help text for the main Vulnerability 
Analysis menu. 

6.4 Outputs 

The following sections describe the expected outputs provided by the System Vulnerability Analyzer 
application. 

6.4.1 Operator's Vulnerability Analysis Display and Analysis Log 

The Vulnerability Analysis results are output to a log file and then displayed to the operator in a scrollable 
window. Both critical nodes and the most vulnerable links for attacking the cnncal nodes are recorded in the 
analysis output file and displayed to the user. The critical nodes are displayed in a descending order based on 
the score. Both the node cnncaliry score and the link vulnerability score fall within the scale of one to ten 
inclusive. The following information is displayed in the log: 

a) Cnncal SCP node point code and office name. Note that the cnncal SCP node is not 
applicable for POTS. 

b) Number of cnncal nodes. 

c) Cnncal node charactensncs including the office name, point code, cnncaliry score, and 
the raw cnncaliry score. 

d) Link informanon referenced to the cnncal node including the link identification, 
connecting node office names, and the vulnerability score. 

e ) Five most cnncal SSPs for each SSP type - tandem, end office, and telephone operator 
position service (TOPS). 



6.4.2 (U) Operational Error and Warning Messages 

The opcranona! error and warning indications which are specific to the Vulnerability Analvzer and displayed 
to the user via the GUI are described in Table 6-3. General System error messages in Table 5-5 which applv 
the Vulnerability Analyzer are identified as either Process Manager or Display Management. 



Table 6-3 - Vulnerability Operational Error and Warning Messages 



Error / Warning Message 


Description of Error/Warning 


Action Required 


Readjust SCP ranks 


There is not a unique SCP identified as the 
most cnncal SCP because of the selected 
service rankings. 


Adjust the Services Rankings and 
restart the Vulnerability Analyzer. 


Too many cnncal nodes 


The number of nodes identified as cnncal 
exceeds the node display limit in the 
configuration file. 


On the command line of the UNIX 
shell, edit the configuranon file 
that was loaded. Reload the 
modified file via File i Retneve. 
and restan the Vulnerability 
Analyzer. 


Database problem expenenced 


A problem occurred in trying to wnte the link 
vulnerability score to the database based on the 
number of hops that the link is from the critical 
node. 


No action. 


Message NOT sent to 
Vulnerability Analysis 


Unsuccessful status returned when attempting 
to send a message to the Vulnerability Analysis 
process via the message queues. 


Restart program. 
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Error / Warning Message 


Description of Error/Warning 


Action Required 


Cannot overwrite existing file 


Selected filename is read-only. 


Select another filename and 
re save. 


Could not open <filename> file 
to display. 


Error occurs if the selected configuration or 
analysis file cannot be retrieved, or if the user 
selects help and there is no help file. 


Correct spelling of filename when 
prompted for filename to retrieve. 


Monitoring point problem 
detected <SSP point code> 


SSP point code specified is not in the database. 


Under "Rankings : SSP . enter 
correct point code. 


Could not open <filename> 


Filename to be retrieved cannot be opened. 


Check path name and filename 
spelling. Check file permissions. 


Unknown field: <filename>. 
Must be Disabled or Enabled. 


In configuranon file the opnons for the fault 
log are either Disabled or Enabled. 


On the command line of the UNIX 
shell, edit the configuration file 
and type either Disabled or 
Enabled for the fault log. 


XENVTRONMENT not set. 
Needs to point to "gui.res" file. 


Environment variable not set up correctly to 
point to the GUI's resource file. 


Correct environment vanabie 
setup. 



In addition, faults are logged by the Vulnerability Analysis process into its corresponding flat file with a default 
name ofvulnerabilirv_analyzer_class.log. The fault log can be enabled or disabled by the system configuranon 
file previously loaded. Refer to Table 6-4 for a list of possible messages that may appear in the fault log. 

Table 6-4 - Vulnerability Fault Log Messages 



Error Message 


Description of Error 


Error writing SCP node cnricality to 
database for <SCP point code> 


Unable to write the specified SCP's crincality score to the 
database. 


Error writing SSP node crincality to 
database for <SSP point code> 


Unable to write the specified SSP's crincality score to the 
database. 


Error writing STP node cnticality to 
database for <STP point code> 


Unable to wnte the specified S LP's crincality score to the 
database. 


Message Queue OPEN Error detected 
bv Vulnerability - Aborting program. 


Status is bad for either the Vulnerability incoming message 
queue or the Vulnerability outgoing message queue to the GUT. 


Message Queue SEND Error detected 
from Vulnerability to Display Manager. 


Error detected in trying to send a message to the Display 
Manager. 


Node/link correlation not performed. 
Too many criucal nodes identified. 
Critical node count is x. (x is an 
integer). 


The number of identified critical nodes exceeds the node display 
limit specified in the configuration file. 


Numencal error with STP <STP point 
code> net score denominator. 


Identified STP would be a divide by zero as the number of hops 
to the critical SCP is zero. 


Unable to initialize scores in database. 


Call to database to initialize the node and link scores was 
unsuccessful. 


Vulnerability is unable to get STP 
linksets. 


The database was unable to return the linkset for the S 1 H 


Vulnerability is unable to set net score 
for linkset <linkset name> 


Error in trying to write the link score to the database for the 
specified linkset. 
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7. (U) Notes 

3=£r ral mfomarion *" aids fa *• (e ,. background 

7.1 (U) Abbreviations and Acronyms 

All abbreviations and their meanings, as used in this doc^n, , 

hs *»* 10 *" dOCUme^, ' 316 P resented » *e followng alphabetical 

DPC Designation Point Code 
GMT Greenwich Mean Time 
GUI Graphical User Interface 

If tote 8«w«i Services Digital Network 

ISUP ISDN User Pan 

MTP Message Transfer Pan 

OPC Origination Point Code 

POTS Plain Old Telephone Service 

SCP Service Control Point 

SS7 Signalling System 7 

SSP Service Switching Point 

STP Signalling Transfer Point 

SUM Software User's Manual 
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(U) Topology Database Schema and Procedures 

This section describes the information and instructions necessary for uw . • ^ ■ 

Database. The foUowing ,s the step-by-step procedure n^^XZ Sys^Ll^ 01 ^ 

Prerequisites: 

LOG FN: sa 
PASSWORD: 

Minimum size of tempdb database: 24MB 
Data device named data_device_ 1 
Index device named indexdevice 1 

Run the following script to create the systemdb database: 

i S5VSTEMHOME/db/db_scheraa/system_db_inic . sql 

Run the following script to create the tables in the system_db database- 

% SSYSTEMHOME/db/db_schema/creace_all_sy S cern_db_tables 

Run the following script to create the required stored procedures for the Intrusion Detector and the 
Vulnerability Analvzcr in the system_db database- 

4 SSYSTEMHOME/db/dblprocs/crea t e_aU_syscem_s C ored_procedures 

System Database Schema 

The following tables descnbe the System database schema used by both the Intrusion Detection and 
Vulnerability Analysis tools. The highlighted rows within the tables indicate a unique primary key. 

Table 7-1 • Nodes Table Description 



NODES Table 



Description 



CLLI 



LATITUDE 



LONGITUDE 



NODE TYPE 



char(1 1 ) 



numeric(7,5) 



numeric(8,5) 



int 



not null 



null 



Common Language Location Identifier 



null 



NET CODE 



NET CRITICALITY 



not null 



int 



numeric(7,3) 



Type of node: 

0 = Unknown 

1 = STP_NODE 

2 = SSP Access Tandem Switch 

3 = Operator Services SSP Switch 

4 = SP/SSP End Office 

5 = SCP 

6 = AIN SCP 



not null 



null 



Latitude of node (Ex. 38.12651) 



Longitude of node (Ex. -76.873321 



Network code of SS7 point code TBD 



Vulnerability analysis node criticality raw 
score 



CRITICALITY SCORE 



numeric(5,3) 



null 



OCCUPANT COUNT 



Vulnerability analysis node criticality 
normalized score 



int 



null 



REMOTE ACCESS 



tinyint 



null 



Number of people working at node facility 



SECURITY_OBSERVATION bit 



not null 



external log on access to node 
REMOTE PUBLIC, REMOTE PRIVATE) 



Facility access monitoring (Yes/No) 



Table 7-2 - Node Types 



NODE_TYPES Table 



Description 
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NODE STRING 



varchar(30) 



not null 



Textual description of node type: 

Unknown 

STP_NODE 

SSP Access Tandem Switch 
Operator Services SSP Switch 
SP/SSP End Office 
SCP 
AIN SCP 



Table 7-3 - Links Table Description 




NUM LINKS 


tinyint 


null 


Number of physical links per link set 


LINKSETTYPE 


char(2) 


not null 


GTE nomenclature for linkset type derived 

from LINKSET_NAME: 

AG = A-link to gateway switch 

Al = A-link to independent carrier switch 

AL = A-link to other LEC 

AM = A-link to mobile carrier 

AP = A-link to SCP 

AQ = A-link to AIN SCP 

AS = A-link to SSP access tandem switch 

AT = A-link to operator services SSP switch 

AU = A-link to SSP end office 

Bl = B-link to independent carrier STP 

BM = B-link to mobile carrier STP 

BN = B-link to GTE non-mated STP 

BR = B-link to RBOC STP 

Dl = D-link to independent carrier STP 

DM = D-link to mobile carrier STP 

ON = D-link to GTE non-mated STP 


MEDIA_TYPE 


tinyint 


null 


Physical link media: 

0 = FIBER MEDIA 

1 = MICROWAVE MEDIA 

2 = SATELLITE MEDIA . 

3 = COAX MEDIA 


TRANSMISSION PROVIDER 


tinyint 


null 


Transmission facilities service provider for 
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LINKS Table 






Description 








hnkset designated by SS7 network point code 
(Ex. GTE = 240) 


DCDrCMT 1 ITN l7ATiriM 

r*cr\L»Cf>l l_U 1 ILI^A 1 IUN 


numeric(6,3) 


null 


Percentage of link capacity utilized (based on 
56kbps) 


PERCENT_GEN_EXTERNAL 


numeric(6,3) 


null 


Percentage of link capacity generated 
outside of GTE network 


SECURITY_ENCRYPTION 


bit 


not null 


Linkset encryption capability (Ex. FALSE = 0) 


SECURITY_MONITORING 


bit 


not null 


Linkset monitoring capability (Ex. FALSE = 0) 


POINT_CODE_SCREENING 


tinyint 


null 


Type of STP point code screening employed 
on the linkset: 

0 = NO_PCODE SCREENING 

1 = NETWORK 

2 = NETWORK CLUSTER 

3 = NETWORK CLUSTER MEMBER 


LOGIC_SCREENING 


tinyint 


null 


Type of STP logic screenina erriDlovpri nn the 
linkset: 

0 = NO_LOGIC_SCREENING 

1 = MESSAGE CLASS 

2 = MESSAGE TYPE 


NET_VULNERABILITY 


numeric(5.3) 


null 


Vulnerability analysis inherent link 
vulnerability score 


VULNERABILITY_SCORE 


numeric(5,3) 


null 


Vulnerability analysis link vulnerability score 
based on critical node analysis 



Table 7-4 - Link Services Table Description 




Table 7-5 - SCP Table Description 



SCP Table 






Description 


SCP^P01NT^CODE?£^^*I 


mom* 






NUM_OF_SVCS 


int 


null 


The number of services accessed by the SCP 


LINK_OCCU_SUM 


real 


null 


Summation of the link occupancy for all links 
directly connected to SCP node 
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Table 7-6 - SCP Services Table Description 



SCP SERVICE Table 




Description 



null 




Table 7-7 - STP Table Description 





STP Table 






Description 












SSP_COUNT 


int 


null 


Number of SSP nodes directly connected to 
STP node 


POTS_LINK_OCCU_SUM 


real 


null 


Summation of the link occupancy for all links 
connected to STP node except links 
connected to a SCP node 
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STP_SERVICE Table 




Description 








includes directly connected SSP nodes and 
SSP nodes of children STP nodes. (Roll-up) 




real 


null 


Summation of the link occupancy for all links 
directly connected to STP node for a 
particular service 




Table 7-9 - 


SSP Table Description 


SSP Table 






Description 








fpSiliJffi feBW^MriilBBIaHiail 


CUSTOMERJMPORTANCE 


tinyint 


null 


Ranking between 1 and 10 indicating relative 
importance of an SSP node in the vulnerability 
analysis (user input parameter) 


LINK_OCCU_SUM 


real 


null 


Summation of the link occupancy for all links 
directly connected to SSP node 



Table 7-10 - SSP Service Table Description 
SSP_SERVICE Table Description 




Table 7-11 - Network Codes Description 



NETWORK_CODES Table 




Description 


CODE_STR 


char(3) 


not null 


CODE represented as a string (Ex. "240") 




iT.llillMiV • <; 






CO 


varchar(40) 


not null 


Company assigned to the network code (Ex. 
240 is GTE Service Corp/Telephone Ops) 



Table 7-12 - Trunk Neighbor Description 
TRUNK_NEIGHBOR Table Description 




Table 7-13 - Locations Table Description 
LOCATIONS Table Description 
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LOCATIONS Table Description 




CLLI (Ex. MANASSAS, VA) 
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I. Scope 

1.1 System Overview 

The System Network and Signal Infrastructure Vulnerability Analysis and Intrusion Detection System 
(hereafter referred to as the system) is a software application capable of providing real-time protection 
the U.S. telecommunications Signaling System No. 7 (SS7) infrastructure. 



The goal of the system is to perform the following: 



a) Determine the vulnerability of the SS7 network based on its topology and identify the 

network elements most vulnerable to intrusion, 
a) Detect intrusions to SS7 links being monitored 

a) Provide a User Interface for operator control and status display in support of the above 
processes. 

The system uses a Sun Microsystems "s SPARC-20 platform, running the Solaris 2.5 operating system. 

1.1 Document Overview 

This Design Description (SDD) describes the design for the system. The system CSCIs is being modeled 
with the Object Modeling Technique (OMT) Object-Oriented Analysis/ Design methodology, using the 
Rational Rose/C++ Computer-aided Software Engineering (CASE) tools. This system software includes 
the following Computer Software Configuration Items (CSCIs): 

a) Intrusion Detector (including SS7 Monitoring, User Interface, Anomaly Detection 
process) 

a) Vulnerability Analyzer (User Interface, Vulnerability Analysis processes) 
a) Topology Database 

1. References 

The documents identified below provide background material and are incorporated herein by reference. 
DOCUMENT No. TITLE 



[1 ] ISO 9001 International Organization of Standards 9001 

[2] ANSI Tl.l 1 1-1996 Signaling System Number 7, Message Transfer Part (MTP), American 

National Standards Institute Inc., 1996 

[3] ANSI T 1 . 1 1 2- 1 996 Signaling System Number 7, Signaling Connection Control Part 

(SCCP), American National Standards Institute Inc., 1996 

[4] ANSI Tl. 1 13-1995 Signaling System Number 7, Integrated Services Digital Network User 

Part (ISDN), American National Standards Institute Inc., 1995 

[5] ANSI Tl. 1 14-1996 Signaling System Number 7, Transaction Capacity Application Part 

(TCAP), American National Standards Institute Inc., 1996 

[6] ANSI Tl . 1 16-1990 Signaling System Number 7, Operations, Maintenance and 

Administration Part (OMAP), American National Standards Institute 
Inc., 1990 
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1. CSCI-wide Design Decisions 

This section presents the CSCI-wide design decisions, that is. the decisions common to all the CSCIs 
behavioral design and those of its software subunits. The following functionality resides in the Common 
Infrastructure of the software architecture, accessible to all other CSCIs. 

1.1 Interprocess Communication (IPC) 

These section details the UNIX System V IPC methods used to implement interprocess communication 
whereby two or more processes communicate with each other to perform tasks. These three mechanisms 
listed below, are available for use in the design as needed. 

a) Message Queues 
a) Semaphores 
a) Shared Memory 



Message queues are a preferred method for IPC since they are easier to manage and are easily ported to 
other processing environments. Snared memory is used when higher performance is required, since the 
data is shared rather than copied between the different data regions as is done in the implementation of 
message queues. The following subsections give an overview of each of the three IPC options. 

1.1.1 Message Queue 

The message queue allows multiple processes on the same machine to exchange formatted data by sending 
and receiving messages among themselves. The messages stored in a message queue are persistent even 
when there is no process referencing the queue. Messages are removed from a queue only when processes 
explicitly retrieve them. 

Within the Common Infrastrucrure library, a MessageQueue class is provided to interface to the embedded 
message queues of the UNIX kernel. It is through this interface that two independent processes are able to 
pass messages between each other. A typical class hierarchy utilizing the MessageQueue class is shown in 
Figure 0-1 . Here, we see classes of different processes, the SERVER class and the CLIENT class, and their 
relationships with the MessageQueue class using the OMT notation. 
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Server 



ExecuteMessageQ 



I 



MessageQueue 



State : irtt 



Message Queue{ ) 
Statu sOK( ) 
RemoveQueue{) 
SendMessage() 
GetMessaqcQ 



Client 



PaisMessage() 



Figure 0-1 - Class Diagram: Message Queue 



Figure 0-2 is an example scenario diagram showing how two independent processes can utilize the 
MessageQueue class. The SERVER and CLIENT objects must, first, instantiate their own MessageQueue 
objects using the MessageQueue constructor function. At this time, the IPC link is established. The status 
of the queue is then verified by the StatisOK() function. By using the SendMessage() and GetMessage() 
operations of MessageQueue class, the processes are able to pass messages between them. 
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3: ExecnlcMesuge ( ) 



*: GetMesugc (void*.|nt int. unsigned* ) 



5: PusMcuagc( ) 



I 

I 6: ScndMnsagc (coon void*. Int. iol) 



7- RemovtOurue ( ) 



1 



Figure 0-2 - Scenario Diagram: Passing a Message example 

The following system-imposed limits on the manipulation of messages are defined in the <sys/msg.h> 
header file: 



a) the maximum number of messages queues 

a) the maximum number of bytes of data allowed for a message 

a) the maximum number of bytes for all messages allowed in a queue 

a) the maximum number of messages in all queues allowed in a system 

1.1.1 Semaphore 

Semaphores provide a method to synchronize the execution of multiple processes. Semaphores are 
frequently used along with shared memory to establish a method for IPC. Like messages, semaphores are 
persistent, despite their creator process's termination. 

1.1.1 Shared Memory 

Shared Memory allows multiple processes to map a portion of their virtual address space to a common 
memory region. Thus, any process can write data to a shared memory region and the data are readily 
available to be read and modified by other processes. 



The data in a shared memory region are persistent The memory space is not deallocated even if the process 
creating the shared memory region terminates. Also, shared memory does not provide any access control 
method for processes that use it, semaphores are used with the shared memory to implement this 
interprocess communication media. 



1.1 Process Management 

This section outlines the high-level generic process management scenarios of the System's Intrusion 
Detector. The following scenarios are addressed: 
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a) Initialization 

a) Self-test operations 

1.1.1 Initialization 

Upon launching the System Intrusion Detector application there are a set of generic : software conjuration 
and control scenanos that are performed. The following defines what is required and conforms to the set- 
up procedures of the system. 

a) The Process Manager (within the Display Management) creates the following child 
processes: 

i) the Intrusion Detection process 
i) the Data Collection process 



a) 



When the Process Manager (within the parent process) creates a child process, the 
Process Manager stores following information about the child: 

i) the child's process identification assigned by the UNIX kernel 

i) the system time at the time of creation 

i) the file name EXECuting in the process 

i) zero out statistics unique to the process 

a) Once a child process is created, the child process initializes itself in the following matter. 

i) prepares to send heart beat messages to the Process Manager, 

i) close all unnecessary file descriptors 

i) change working directory to ROOT. This allows unmounting of filesystem 

i) reset the file access creation mask 

i) run in background 

i) disassociate from inherited process group by making the process group ID equal 
to process ID. Daemon no longer susceptible to signals sent to enure process 
group. 

i) ignore terminal I/O signals 

i) signals, process groups and control terminals revisited 

i) disassociate from control terminal 

i) don't reacquire a control terrninal 

i) handle SIGCLD signals 

a) All processes open/create and initialize its message queue for IPC operations. Verify that 
the message queue status is operational. 

a) Read relevant configuration information, if any, and configure based on that informanon. 

a) At the completion of the process's initialization, each process waits for an indication 
(semaphore) from the parent process. 

1.1.1 Self-Test 

The section defines the implementation of the System's self-test requirements. 
1.1.1.1 Process Verification 

This section defines the requirements for process verification and management for the System applications. 
Each process will be monitored by the parent process using a heart beat IPC messaging. 



62 

SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 



PCT/US99/17408 



APPENDIX C 
SOFTWARE DESIGN DOCUMENT 

Once a child process is created, the child process prepares to send heart beat messages to 
the Process Manager at a fixed time interval of TBD seconds. The format of the heart 
beat message is as follows: 

i) Message Type - indicating it is a heart beat message 

i) Process Identification - assigned to the sending process during its creation, 

i) Time of transmission - system time when the message was queued to the parent, 

i) Process Stats - unique to the particular process. 

Once the child process sends the heat beat message to the Process Manager (parent), the 
child process repeats the scenario in preparation for its next heart beat message when the 
next time interval is reached 

The Process Manager verifies that the child's operation is NORMAL using this heart beat 
message. 

i) If the heart beat is received successfully, the Process Manager records the 

occurrence and stores the process's statistics for later reference. 

i) If the heart beat is not received successfully, the Process Manager: 

a) records this occurrence, via a counter 

a) sends a KILL signal to the child 

a) resets/restarts that process, 

a) notifies the operator, via the GUI 

a) records the event in a error log file. 

1.1.1.1 Common Functional Verification 

This section defines the implementation for software functional verification and management for the 
System applications. Each process will be monitored by the parent process using a heart beat IPC 
messaging. 

a) Verify the status of the queues and check for OVERFLOW condition. The error is 
flagged and written to the local Operator Interface Status Queue. 

a) Verify data for out-of-bounds condition. 



a) 
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Architectural Design Overview 

This section details the overall software architecture for the System. Figure 0-1 shows the data flow 
between the different processes and the external interfaces of the Intrusion Detector and the Vulnerability 
applications. 

The architecture includes two (2) independent applications, the Intrusion Detector and the Vulnerability 
Analyzer, each with its own GUI environment. These processes and the interfaces are discussed in greater 



Intrusion Log 
(Text Listing ) 




SS7 Test File 



UvUhdfid 

;> gdfgdfga 
I) f|df|df| 
41 df 



Monitoring 
Analyzer 



Vulnerability 
Log 

(Text Listing) 



Figure 0-1 - Data Flow Diagrams 



detail within the next subsections 



a) The Intrusion Detector: A real-rime application, including three concurrent processes: the 
Data Collection, the Intrusion Detection and it's Display Management processes. 

a) The Vulnerability Analyzer includes two processes - the Vulnerability Analysis 
and it's Display Management processes. 

The system's class category diagram is shown in Figure 0-2 using the OMT notation. The class category 
diagram illustrates the logical collections of classes used by the applications. It maps well to the software 
architecture diagram presented earlier, however, the significance of this diagram shows the relationships 
and dependencies between these logical class groupings, including the Common Infrastructure category. 
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The Common Infrastructure is an abstraction layer, used to folate the rest of the applicant from the 
details of the low-ievel, operating system-specie functionality for portability to other DhrfoI« i? 
repository of common functionary of multiple processes ,DO JESS mtSaces 1.T " 3 
implemented as a domatn-specif.c framework or library, available to the higher-level subsystems to 
maximize reuse and standardization. suosystems to 

1.1 Intrusion Detector 

This ; section describes the concept of execunoa and the IPC interfaces of the different processes that make 
up the System Intrus.on Detector. The [ntrus.on Detector's architecture ,s parnrioned L three (3) 
mdependent processes - the Dau Collection, the Intrusion Detection and its Display Management 
processes. ° 

1.1.1 Display Management Process 

The Display Management process is the top-level or parent process of the Intrusion Detector and u 
ava.lable during system operation. This process includes the graphical user mterface, des.gned usine the 
SparcWork's V,sua. GUI builder and the Mouf libraries, as well as operations for p ^ L Zl^ 
data for user d.splay. The look-and-feel of the environment is similar to that of the Open Windows 
environment. H umuws 
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1.1.1.1 Interfaces 

The following subsections identify the external interfaces of the Display Management process, as shown in 
the context diagram Figure 0-3. The message queue is the method used for all interprocess communication 
to and from the Display Management process. 

1. 1. 1.1.1 Intrusion Detector Operator Console 



Operator 
Console 



J 



■ Control ana . Statistics 
Configuration . Fau „ Reports 



Data 

Collection 



- Control and 
Configuration 



■ Statistics 
- Fault Reports 

■ Statistics 

■ Faun Reports 



Intrusion 
Detection 




■ Control and 
Configuration 



Figure 0-3 - Context Diagram: Intrusion Detector Display Manager 

The operator console of the Intrusion Detector application is the GUI environment that allows the operator 
to change the application's operating parameters and observe predefined statistics, as well as overall system 
status. 



1.1. 1.1.1. 1 Control and Configuration 

In response to operator selection (via a pull-down menu), the following control and configuration options 
for the intrusion detection process are available. A dialog box is provided to the operator to enter the 
desired selection inputs. 

a) File and Configuration Management: The control options for the system's configuration 
are listed below. When selected, another dialog box is displayed, prompting the operator 
for the desired filename: 
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i) Retrieve Configuration - retrieves a previously saved configuration file from the 

disk drive. 

i) Save Configuration File - saves the current configuration settings to a file on the 

disk drive. 

i) Retrieve Analysis File- retrieves a previously saved log file from the disk drive, 

i) Save Analysis File - saves the most recent analysis results to a log file on the 

disk drive. 

i) Exit - Aborts the application and all its associated processes. 

a) View Management: The control options for the operator's viewing area are listed below. 
When selected, another dialog box is displayed, prompting the operator for the desired 
input(s): 



i) Enter Monitoring Point(s): The operator indicates the current link(s) being 

monitored by the System. The node is entered using its point code designation 
and the links are identified by its linkset number. This action is acknowledged 
by a view of the local SS7 network topology displayed to the operator. Bold 
solid line(s), drawn to the corresponding far end node, indicates the links being 
monitored 



a) Configuration Parameters: With these options the operator is able to adjust and define the 
threshold values used by this application. When selected, another dialog box is displayed, 
prompting the operator for the desired inputs). 

a) Options: Miscellaneous options for test stimulus injection. 



1.1.1.1.1.1 Statistics and Status Display 

In response to an operator selection, the operator can view the following status/statistics. These statistics 
are maintained constantly by the Display Management process. 

a) Network Topology Information: By clicking the mouse's right button on the desired 

node displayed on the topology view. This node information is provided to the operator 
in a scrollable text window. From that window, the operator can select a particular linkset 
of that node and view its characteristics. 



a) Network Statistics: From the environment's main menu bar, the operator can request to 
view the capacity measurements listed below. Information is provided from the Intrusion 
Detection process at a fixed interval. A fault is logged if this message is not received in 
the expected time. 

a) Anomaly Detection Indication: Information is provided from the Intrusion Detection 
process. 

1.1.1.1.1 Intrusion Detection Process 

This section details the Display Management process's interprocess communication to and from the 
Intrusion Detection process. 

1 . 1 .1 .1 . 1 .1 Control and Configuration 

The following IPC messages are sent to the Intrusion Detection Process: 



a) Operator Programmable Configuration Parameters: 
i) MTP operation parameters. 
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') SCCP operation parameters, 

i ) ISUP operation parameters. 

1.1.1.1.1.1 Statistics and Status Display 

The following IPC messages are sent from the Intrusion Detection Process: 

a) Anomaly Detection: In the event that any of the predefined anomaly rules or a 

combtiumon of these rules are satisfied (indicating a detection), a message „ sent to the 
Display Management process for display. The message w„l indicate the folio "ng 
information about the anomaly: 6 

i) the SS7 message 

0 a time stamp generated by the Data Collection process 

• .'! t to * e mle(s) f,rcd which caused ««^y -Pon 

i) the Alarm type 

a) NORMAL operation (initial display) 

a) MINOR 

a) MAJOR 

a) CATASTROPHIC 

a) Network Statistics: The followmg measurements are provided to the D,splav 

Management process at a fixed time uuerval. This message ,s also used bv the D.splav 
Management process as a heartbeat indrcanon from the Intrusion Detecnon process 

0 Total number of messages received per rime rick 

•) Number of MTP type messages received per time tick 

0 Number of SCCP type messages received per time rick 

i ) Number of ISUP type messages received per rime tick 
1 • 1 • 1 • 1 • 1 Data Collection Process 

SLr; ^ss S D ' SPlay MMa8emCDt ProC " S ' S «™«non to and from the Data 

1. 1.1. 1. 1.1 Control and configuration 

The following IPC messages are sent to the Data Collection Process: 

a) Enable/disable test stimulus from file: Wh ra enab i ed , ^ Data CoUecnon 
inject the test stimulus data into the real-tune data stream. 

a) Operator Programmable Configuration Parameters. 
1.1.1.1.1.1 Status and Statistics 

S»J!°^ 8 ^ mCSSa8eS ** fr ° m ±C ° ata C ° lleCt,0n ™ s m «"ge is also used bv the 

Display Management process as a heartbeat indication from the Data Collection process 

a) Total number of messages per sec. 

a) SS7 Link "Heart Beat" indication (as rece.ved from the Monitoring Analyzer) 
1.1 .1.1.1 Topology Database 

d^b«ewTe d n l !f M0 T*° n "* rCtnCVed by ° iSplay M ™*™™ P^ess from the Topology 
deSSS bel 0w * P ° U,t " SPeC,f ' ed ^ *" ° Perat0r ^ DOde ^ ,fak " f °"™ « « 
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a) Nodal Description 

i) Type (R_STP. STP. SSP. SCP. etc.; 

i) Point Code 

i) CLLI Code 

i) Office Name (city, state) 

i) Vendor Name (ATT. GTE. Spruit, etc. ) 

i) Vulnerability Ranking of node (based on result of Vulnerability Analyzer) 

a) Link Descripdon 

i) Linkset Name (See Appendix 0) 

i) Type (A link, ... F link) 

i ) Number of links in Linkset 

i) Occupancy (percentage usage) 

i) Media Type (copper, fiber, radio, etc.) 

i) Vulnerability Ranking of link (based on result of Vulnerability Analyzer) 

1.1.1.1 Concept of Execution 

The Display Management process implements the following funcnonality: 

a) Operator Console Management 
a) Process Management 

1.1.1.1.1 Operator Console Management 

Upon initialization the D IS play Management process displays its operator console w.th all configuranon 
parameters set to the factory default values ( thresholds, etc.). 1, then waits for operator mteracnon Tne 
operator w,H need to provide the configuranon informanon hsted below. This informanon can be loaded 
manually or via loading a pre-defined configuranon flat file. 

a) File Maintenance 
a) Monitoring Point 

a) Threshold values (if different from defaults) 

1. 1.1. 1.1.1 Initialization 

The Display Management process 

a) Retrieve configuranon file information 
1.1.1.1.1.1 Initial Topology View Generation 

Once entered, the monitonng pomt/s) are used to generate and d 1S play the local network topology view 
The network topology v.ew * based on topology informanon retneved from the topology database (nodes 
signal links, etc.). To implement, the GUI performs the following: 

a) get the topology linkset for the first point-code entered from the operator 
a) .fa monitoring point is an A-line. get ,ts corresponding A-Lne mate to the end node and 
include in the drawing 

a) if a monitor point is of a mated STP. draw the interconnecting lines of the STP mated 
pair. 

a) draw local network - all direct links to the monitoring pom. are represented by a regular 
solid luie. For danry. the link(s) selected as being monitored, are represented by a bold 
solid line. 
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I.l.l.l.I.I Topology Maintenance 

Once the local topology „ drawn, the network view reflects the current state of each link of the local 
field from the anomaly detection message. Alarm type da ta 

a) In response to an anomaly detection message from the Intrusion Detecrion process: 

l) Z ^S 1 ""' 5 aD0maly SQms u updated ** d,splaycd m real - ,,me on 

a) BLUE - normal operation (initial display) 

3 ! I! LL0W * C3USed by ^ TKe P* oa °f *e "MINOR" alarm 
3 °„ " C3USed by * e r «cption of the "MAJOR" alarm 

a) RED - caused by the reception of the "CATASTROPHIC" alarm 

As the link's anomaly state .s updated the corresponding anomaly(,es) that caused th, 
condtnon are buffered for operator disp.ay. Tne htghest Lomaly sum JeSS 
pers.sts on the d.splay unnl the operator acknowledges the corresponding aTarms 

The operator acknowledgment clears the alarm buffer for that link and resets the link's 
anomaly siate to "NORMAL operation" (BLUE). 

1.1.1.1.1.1 Test Message Control 
1.1.1 Data Collection Process 

1 .1.1.1 Interfaces 

Co """" " %i ™ " Fis °" ■"■» -»« - *«- - - 



a) 



a) 
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Monitoring 
Analyzer 
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j File 
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Figure 0-4 - Data Collector Context Diagram 



l.t.1.1.1 



SS7 Input Message 



The ujeonung SS7 message, from the monitoring analyzer. is pre-formarted such that each messaee >s of, 
fixed tajth with fixed informanon field,. The expected format for the SS7 message £j £ 



Table 0-1 - Incoming SS7 Message Format 



BYTES 
I 
6 
1 
5 
5 
1 
1 
3 
1 
1 
3 
1 
1 
I 
1 
3 
1 
3 
1 
1 



1 Network Indicator. Priority, Se rvice Indicator 
OPC 



DPC 



Message Type 



Called Address (ISLT called digiB) 



Calling Address (1SUP called digits) 
Called Party Subsystem Number 
Global Title Translation Indicator (Boolean) 



Called Party Point Code 



Calling Piny Subsystem Number 
Global Title Translation Indicator (Boolean) 



Calling Party Point Code 



Data Type fUDT Messages) 
Monitored link message originated 
CIC(ISUP Message only) 



Destination ( 


M 1 Y 1 ransfer Message only) 


Affected SSN 


A 


ffected Point code 



(SCCP Management Message only) 
(SCCP Management Message only) 



DCE or DTE indication 
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l.I.l.t.l Intrusion Detection Process 

The messaging to the Intrusion Detection Process includes the reformatted SS7 messages to be used in the 
intrusion deterrmnat.on The output message format to the Intrusion Detection includes the following 
components: 6 

a) the pre-formarted SS7 input message 

a) a time stamp generated by the Data Collection process 

I. I.I.I. 1 UNIX Files 

The Data Collection process will read and inject the test SS7 messages into the real-time messaee stream 
for purposes of testing. The format and the content of these test messages are identical to those from the 
monitoring analyzer. 

l.I.l.l Concept of Execution 

With the continuing incoming SS7 messages from the commumcanon port. ,t a a requirement that the data 
collection operate in real-time mode. Upon initialization of this process, the incoming SS7 messaees are 
time stamped, reformatted and queued for the Intrusion detection process. 

The top-level class diagram for the Data Collection process is shown is Figure 0-5. The followine is a list 
of the classes, their responsibilities and the collaboranons with the other classes. 

a) Data Collector class is the main class of this process. Its responsibility ts to create 

and control its subclasses at a high level. 
&) T** MessageOueue class resides in the Common Infrastructure category. It is this class 

that represents the IPC method used by the Data Collector. 
ai The CommPon class's responsibility is the control communication port and manages the 

data flow from the port. The SS7 message data structures arc made available to the Data 

Collector class, independent of protocol used by the port, 
a) The File class is the Data Collector's interface to the Unix files. The data structures of the 

test SS7 messages are made available to the Data Collector class, identical to that of the 

CommPort class. 

a) The Clock class is used by the Data Collector as the main timer of the process. 
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SoOiof I 
Send() 



Figure 0-5 - Class Diagram: Data Collector 

Figure 0-6 is the high level scenario diagram for initializing the of the Data Collection process The 
funcnoo meD a uCollcctor: : Ininalize<) u called first and performs the required iiutializanon ' 

cT fnr'nTr Data£ ; ol,eCt0r class ' " weU « Toe foUowing to details the function 

calls for Data Collector initialization: 



a) 
a) 
a) 

a) 



theCommPort-CommPonO - this is the constructor of the CommPort class which sets 
up the communication port for the specified protocol it is to implement 
thelncrusionQueue:. MessagcQueueO - this is the constructor of the Intrusion Detection's 
MessageQueue class, which sets up the [PC link between the rwo processes 
theFile:.FilcDetected() - The DataCollector object verifies the existence of the test 
message file for injection. theDataCollector::EnableFileMsgs() is then called to set the 
proper local flags to enable this operation. 

theaock::SetTimerO - The timer is setup and used to control the test message injection 
into the SS7 message stream from the UNIX file. 
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Figure 0-7 - Context Diagram: Intrusion Detector 



1.1.1.1.1 Network Topology Database 

The Network Topology Database provides the intrusion detection algorithms with the required relevant 
infrastructure data (node and link information) of the SS7 network. The network topology information and 
its format, as required for the intrusion detection, is identical to that used by the Display Management 
process. 

1.1.1.1.1 UNIX Files 

The Intrusion Detection process logs all anomalies detections, as well as the resultant intrusion decision 
The filename is specified by the operator via the Display Management process. 

1.1.1.1 Concept of Execution 

The Intrusion Detection process reacts to an IPC message into its message queue. The thread of execution 
performed is based primarily on the type of this message. Any message type determined to be invalid are 
logged and discarded. The following messages are valid by this process: 



a) 


Statistics Enable/Disable: 


a) 


Fault Log Enable/Disable: 


a) 


Process Start/Stop: 


a) 


Process Shutdown: 


a) 


Monitor Points: 


a) 


SS7 MSU Record: 




SS7 MSU Record 



1.1.1.1.1 

SS7 message is passed into its message queue from the Data Collection process. With every new message 
received, a determination is made whether any anomalies have indeed occurred. 
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Along with the infoimation contained within the newly received SS7 message itself, the detector uses .h, 
■n.ormation from prev.ously captured SS7 messages, as well as network topology ii.fomut.on It then 
correlates ,t results to predefined conditions or rules that would indicate the presence of an anomalies. 
The following conditions are tested at different levels of the protocol. 

a) ISDN User Part (ISUP) messages 
0 Improper RELEASE 

i) Improper BLOCKING and/or CIRCUIT GROUP BLOCKING 

i) Improper RESET and/or CIRCUIT GROUP RESET 

a) Message Transfer Part (MTP) messages 

i) Improper CHANGEOVER (including Emergency Changeover) 

i) AH improper TRANSFER PROHIBIT/RESTRICTED/CONTROLLED 

i) Improper LINK INHIBIT 

a) Signaling Connecnon Control Part fSCCP) messages 
i) Improper Subsystem Prohibited 

i) Improper Subsystem Out of Service 

Whether there was an anomaly detected or not. the current SS7 message is stored and used in future 
anomaly tests. The Intrusion Detection process logs all anomalies detections, as well as the resultant 
intrusion decision. 

1.1 Vulnerability Analyzer 

This secnon describes the concept of execution and the IPC interfaces of the different processes that make 
up the System Vulnerability Analyzer. The Vulnerability Analyzer's architecture is partitioned tnto two n\ 
independent processes, the Vulnerability Analysis and Display Management processes The primary 
responsibility of the Vulnerability Analyzer is to evaluate an SS7 network topology and determine 'the 
locanons most vulnerable to SS7 network intrusion. 

1.1. 1 Display Management Process 

The Display Management process is the top-level or parent process of the Vulnerability Analyzer and is 
available during system operation. This process includes a window-based environment, similar to that used 
in the Intrusion Detector. This was purposefully done for two reasons: 

1 . It is hoped that similar environments (look-and-feel and positioning the control opnons under 
similar pull-downs) may make the tools more user-friendly 

2. Maximize standardization and reuse of the design. 
1.1.1.1 Interfaces 

The following subsections identify the external interfaces of the Vulnerability Analyzer s Display 
Management process, as shown in the context diagram Figure 0-8. The Message queue is the method used 
for all interprocess communication to and from the Display Management process. 
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Figure 0-8 - Context Diagram: Vulnerability Analysis Process Display Manager 



1.1. 1. 1.1 Vulnerability Analyrer Operator Console 

The operator console of the Vulnerability Analyzer application is the GUI environment that allows the 
operator to change the application's operating parameters and observe predefined statistics as well « 
overall system sums. " 

1.1.1.1.1.1 Control and Configuration 

In response to operator selection (via a pull-down menu), the following control and configuranon opnons 
for the (Vulnerability Analysis process are available. A dialog box .s prov.ded to the operator to enter the 
desired selection inputs. 



a) 



a) 



a) 



File and Configuration Management: The control opnons of this pull-down menu is 
identical to that of the Intrusion Detector. 

Thresholds: With these options the operator is able to adjust and defined the threshold 
values used by this application. When selected, another dialog box is displayed, 
prompting the operator for the desired inputs). 

Analyze: The GO indication from the operator, is the signal to begin a new analysis of 
the network. 



1.1.1.1.1.1 



Network Vulnerability Display 
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in response to the ANALYZE COMPLETE message from the Vulnerability An i t, 

the analysts » complete), the Display Management process 1,1 then ~£ * t ^ Proc « 5 

flat fll. for operator disp.ay. Thedatl neldslf the ^^"S^^^ * ™* 

a) the Link or Node name and office name 
a) the criteria satisfied indicating vulnerability 
a) its vulnerability ranking 

1.1.1.1.1 Vulnerability Analysis Process 

This section details the Display Management process's intemrno.« 

Vulnerab.liry Analys»s process interprocess commun.canon to and from the 

1.1.1.1.1.1 Control and Configuration 

The following IPC messages are sent to the Vulnerability Analysis Process: 

a) Operator Programmable Thresholds: These threshold parameters are used hv ,h 
Vulnerability Analys.s process ui support of lB algonLs V 

ai Operanonal Control Messaging: The following indicanons are sent to rh, v . 

Analysis Process to control ,ts flow of operanon: "Inerab.hrv 

^SL"""* " ^ md,CatCS t0 be8W » ™»« '« c-n™, 

1.1.1.1.1.1 Status and Statistics 

Tta following IPC messages are sen, from the V ul nerab,.,ry Analysis Process ,ts Disp.ay Management 

a.) Operational Control Messaging: The followmg indicanons are sent from the 
Vulnerability Analysis Process, reflecting us operanon status: 

0 n£S fil ^ TT " ™ S mdiCat " tha ' '* 3nalySis has b « n «mpl«ed and 

the log file is ready for operator display. 

1.1.1.1 Concept of Execution 

In response to an ANALYZE indication from the operator, the Vulnerability Analyzer s Displav 
Management process sends its own ANALYZE indication to the Vulnerability Analysis ftoS. 

Upon reception of the COMPLETE message from the Vulnerability Analysis Process the Di»l.v 
Management process retrieves the specified Un« flat file containing the vWerVbX icS iSSl 
calculated. It ,s then displayed to the operator v,a ,ts own scrol.ab.e texJd^ly ^ J "" 

1.1.1 Vulnerability Analysis Process 

The Vulnerability Analysis evaluates the current SS7 network topology and ranks the each «»m, „<■ a 
network infrastructure, based on its vulnerability to potenrial motions * °' 

1.1.1.1 Interfaces 

The context diagram, shown in Figure 0-9, identifies the multiple IPCs needed by this subsystem. The 
following subsections address these interfaces. »u°sysicm. i ne 
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l.l.l.i.i 



Figure 0-9 - Context Diagram: Vulnerability Analysis Process 
UNIX Files 



Once the analysis of the network ts complete, the Vulnerability Analv^k „„,,-.. ^ 

L-NIX flat file for future retneval and display by the dS W ? ^ ,B rMultS mt0 a 

text file are as follows: P V Mana 8 em «" P"*e«. The text fields in this 



a) 
a) 
a) 



1.1.1.1.1 



the Link or Node name and office name 
the criteria satisfied indicating vulnerability 
its vulnerability ranking 

Network Topology Database 



The Network Topology Database provides the vulnerability analysis algorithms with th<- a , 

infrastructure data of the SS7 network Th<- n,*™^ , . Z al 8 0nu «ns with the required relevant 

the vulnerabLity analysis L iStlow « Bl ta ^ « *«»™» 



a) 
a) 
a) 
a) 

a) 



Numerical weights for Physical Accessibility of the each link and node 
Numerical we.ghts for Functional Accessibility of the each link and node 
Numerical we.gbts for Security Capability of the each link and node 

ne^rk" 1 WCl8htS NOde ° ndCality ° f Wh DOde - fClanve w surroundmg 
Link and node information. 



1-1.1.1 Concept of Execution 
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Information about the network's infrastructure is retr.eved from its database (topology and link/node 
vulnerab.hry relationships) and used in its algorithms. The followng aspects of the network are analyzed 
for each vulnerability determination: 



a) 
a) 
a) 

a) 

a) 



Physical characteristics - the media type used (copper, fiber, etc.) 
Functional characteristics - the services provided on the link/node 
Security characteristics - the existing screening measures (on-line, encryption 
observation, etc.) 

Node Criticality - the importance of the network element with respect to the its usaee and 
capacity. 5 

Redundancy - availability of alternate routing around element. 



As a network entry is evaluated, a resultant message is sent to the specified text log file (UNIX flat file) 
This is the file that the Display Management Process retrieves for operator display. 

At the completion of the analysis, a COMPLETION message is sent to the Display Management process 
indicating that the analysis results are available for display. 

1 . 1 Network Topology Database 

The Nerwork Topology Database is the persistent storage for the GTE SS7 nerwork infrastructure It 
contains all the nodal and link information required to implement both the Intrusion Detector and the 
Vulnerability Analyzer processes. 

1.1.1 Interfaces 

The context diagram, shown in Figure 0-10, identifies the multiple IPCs needed by this subsystem. 
Access to the topology database, via the SYBASE SQL Server, is accomplished using the SYBASE 'Open 



Display 
Management 



■Carmtn 



T 
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NKKrt rapetogyCHa 



Figure 0-10 - Network Topology Database Domain Diagram 
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Cl.ent" L.brary. Th.s truce parry library u a collection of utility routines tha, « 

database. ,ly rou,ln « ">at is our mam interface to this 

1.1.1 Concept of Execution 

From the C-- environment, the Topology database is accessed via the Databasefm^f , 

external intertace satisfies the operational requirements of the ^rt^^nTu^ ^ 

--PP-as, .soothe Open abt^^^J^d. 

In response to a function call by a client process, to the Databaselnterface class ,h. „ . 

requtred data se, as defined by ,ts external interface functional s^alure the 

Intrusion Detection Algorithms 

This section presents a high-level detail of the specific algorithms used in de^m,,n t 

anomaly event within the GTE SS T network. ^ possibility of an 

MTP Message Validation 

currently being monitored by the Secure? IDS. ' ^ P eno ™^ on links 

a. The followtng SS7 MSU of type MTP arc supported by the System Intrus.on Detector: 

D Changeover (CHANGEOVER. CHANGEOVER ACKNOWT Enr.F ru.v^n 

CHANGEBACK ACKNOWLEDGE. EMERal^^S^^?^ 
CHANGEOVER ACKNOWLEDGE) "-"A^utuvER. EMERGENC : 

i) Transfer Prohibit/Kestnct 

0 Signaling Route Set Test 

i) Transfer Allowed 

i) Transfer Control 

i) Signaling Route Set Congestion Test 

.) Management Inhibit (Link Inhibit Link Inhibit Acknowledge Ltnk Local Test s.on,! t l. „ 

Test Signal. Link Force UninJabit. Link Uninhibit) ^ Lmk Remote 

a) For ail SS7 MSU messages, the following actions and checks wiU be performed. 

i) Maintain and threshold the number of occurrences of each of the MSU rv™.< ™a a 

SLCto their corresponding adjustable threshold. A. telS 2S ot^Tn -f 

number of occurrences exceed its corresponding threshold. "d log file .t the 

,) Validate SS7 routing label of each MSU. The link connection, based on the message's OPC and DPC 
^^T Ba mfonnaaon of ** GT * N«^ork topology database , LINKVEAREST 
NHGHBOR «,. An alarm ,s declared to the GUI and .0^ a link r^an^hTp d^nolex.s, 
Ttadheck wul also venfy onginanng pom. code (OPQ does not eoua. the des.gnanon po™ code 

MTP Messages 

Upon recepnon. the following tests will be performed on all MTP messages. 

^ SnT r " ^ reCePn ° n ° f * C"*"™ 0 ™ MT P ™s**ge. no additional tests axe 
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a) Emergency Changeover - Upon reception of an EMERGENCY CHANGEOVER MTP message 
no additional tests axe performed. 

a) Changeover/Emergency Changeover Acknowledge • Upon reception of a CHANGEOVER 
ACKNOWLEDGE MTP message, the following tests are performed. 

i) Verify that a corresponding CHANGEOVER or EMERGENCY CHANGEOVER was 
previously detected on the same link. An alarm is declared to the GUI and log file if no 
previous Changeover was not detected. 

a) Transfer Prohibit/Restrict - Upon reception of a TRANSFER PROHIBIT or a TRANSFER 
RESTRICT MTP message, the following tests are performed The tests related to the destination 
point code, referred to by this message, is only done if that link is also being monitored. 

i) Relative to the thresholding the number of occurrences of nodal and node cluster prohibits 
and restricts are maintained separately and thresholded to its corresponding adjustable 
threshold. An alarm is declared to the GUI and log file if the number of occurrences exceed 
its corresponding threshold. 

i) Verify the OPC of this message, corresponds to a Signaling Transfer Point (STP). These 
message types arc only expected to originate from a STP. 

i) Verify the destination point code, referred to by this message, corresponds to a node directly 
connected to the originating STP in which the message was sent. 

i) Verify that at least one of the following message types was previously detected on the 
destination link, referred to by this message. An alarm is declared to the GUT and log file if 
none of the following messages are detected (If the destination link, referred to by this 
message, is not part of the local topology defined, then this item will not be checked). 

( 1 ) EMERGENCY CHANGEOVER/CHANGEOVER - its DPC should be the same as the 
OPC of the original TRANSFER PROHIBIT/RESTRICT message on the other link 

( 1 ) LINK INHIBIT - its direction is irrelevant 



( I ) TRANSFER PROHIBIT - due to a STP broadcasting a link redirection. 

a) Signaling Route S«t Test - Upon reception of a SIGNALING ROUTE SET TEST MTP message, 
the following tests are performed. An alarm is declared to the GUT and log file if any of the 
following conditions axe FALSE: 

i) Verify that a TRANSFER PROHIBIT or TRANSFER RESTRICT message was previously 
detected on the same link in the opposite direction (OPCs and DPCs are reversed) 

a) Transfer Allowed - Upon reception of a TRANSFER ALLOWED MTP message, the following 
tests are performed. An alarm is declared to the GUI and log file if any of the following condinons 
are FALSE: 

i) Verify that a SIGNALING ROUTE SET message was previously detected on the same link in 
the opposite direction (OPCs and DPCs are reversed). 

i) Verify that the total number of SIGNALING ROUTE SET TEST messages detected on this 
link, before a TRANSFER ALLOWED message, is greater than one (1) (SOFT ALARM). 
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each hnkset and .demifies any non-random inhibmng of consecutive SLCs of a links* An 
adjustable number of consecutive SLCs inhibited are identified as an INTRUSION 

Link Local Test Signal - Upon reception of a Management Inhibit a LINK LOCAL TFST cirv r . i w-n. 
message, the following tests 3re performed. An a|ann 8 „ dedafed ^ q 1^7 S,GN ^ *™ 

following conditions axe FALSE: '° 8 fi ' C ' f My °« the 

0 Venfy that a LINK INHIBIT ACKNOWLEDGE message was prev.ously detected on the 
same link in the opposite direction (OPCs and DPCs are reversed) This messaae 1 mi 
de^rL^ 1017 ACKNOWLEDGE *< ™ Je^noTp"ra^e f l° g W 

.) Venfy that at leastrwo (2) consecunve LINK LOCAL TEST SIGNAL messages are detected 
on the same link. The second message must follow the first LINK LOCAL TEST SIGN a r 
message within the T20 timer period plus a processing delta tune. 

a) Link Remote Test Signal - Upon recepnon of a Management Inhibit a LINK REMOTE TEST sign a i 
MTP message the following tests are performed. An alarm » declared to the GUI and : 0 g file • A„v of -he 
following condmons are FALSE: 5 " - 01 - ne 

.) Venfy that a LINK INHIBIT ACKNOWLEDGE message was prev.ously detected on the 
same link in the same direcnon (OPCs and DPCs are the same). 

0 A LINK REMOTE TEST SIGNAL message must follow a LINK INHIBIT 

ACKNOWLEDGE message within the T21 timer period plus a processing delta tune. 

i) Venfy that at least two (2) consecunve LfNK REMOTE TEST SIGNAL messages are 
detected on the same link. The second message must follow the first LINK REMOTE TEST 
SIGNAL message within the T2 1 tuner period plus a processing delta tune. 

a) Link Force Uninhibit - Upon reception of a Management Inhibit a LINK FORCE UN INHIBIT MTP 
message, the followuig tests are performed. An alarm is declared to the GUT and log file if anv of the 
following conditions are FALSE: 



1 > ^ a LINK LOCAL TEST SIGNAL message was previously detected on the same 

link in the opposite direcnon (OPCs and DPCs are reversed). 

i) A LINK FORCE UNINHIBIT message must follow the LINK LOCAL TEST SIGNAL 
message within the T20 timer period plus a processing delta tune. 

a) Link Uninhibit - Upon reception of a Management Inhibit a LINK UNINHLBIT MTP message the 
followuig tests are performed. An alarm is declared to the GUI and log file if any of the followme 
conditions are FALSE: 6 

.) Venfy that a LINK REMOTE TEST SIGNAL message was prev.ously detected on the same 
link in the opposite direcnon (OPCs and DPCs arc reversed). 

0 A LINK UNINHIBIT message must follow the LINK REMOTE TEST SIGNAL message 
within the T2 1 timer penod plus a processing delta tune. 



82 



SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 



PCTAJS99/17408 



APPENDIX C 
SOFTWARE DESIGN DOCUMENT 
ISL'P Message Validation 

All SST MSL' messages of type ISUP are analyzed for inconsistencies within their data fields as compared 
to the SST ANSI specificanon. The ISUP tests described within this section ire only performed on links 
currently being monitored by the Secure7 IDS. 

a) The following SS7 MSU of type ISUP are supported by the Secure7 IDS: 
0 Initial Address 

ii) Address Complete 

iii) Release 

ivj Release Complete 



b) 



For all SS7 MSU messages, the following actions and checks will be performed.. 

i) Maintain and threshold the number of occurrences of each of the MSU rypes and 

functions to its correspondmg adjustable threshold. An alarm is declared to the GUI and 
log file if the number of occurrences exceed its corresponding threshold. 

in Validate SS7 trunk connection between the message s OPC and DPC . TRUNK 

NEAREST NEIGHBOR test). An alarm is declared to the GUI and loe 'lie f a trunk 
relanonship does not exist This check w,U also venfy originating pomt code .OPC) does 
not equal the designation point code (DPC). 

ISL'P Messages 

Upon reception, the following tests will be performed on all ISUP messages. 

a) Initial Address - Upon recepnon of a rNTTlAL ADDRESS ISUP message, the following tests are 
performed. An alarm is declared to the GUI and log file if any of the following conditions are FALSE. 

.) Venfy that the CIC. referenced by the INITIAL ADDRESS message, was not currently allocated. 

a) Address Complete- Upon recepnon of a ADDRESS COMPLETE ISUP message, no additional 
tests. 

a) Release - Upon recepnon of a RELEASE ISUP message, the following tests are performed. An alarm .s 
declared to the GUI and log file if any of the following condinons are FALSE: 

i) Venfy that a INITIAL ADDRESS. ADDRESS COMPLETE or an ANSWER message was 
previously detected on the same link. 

.) Verify that the CAUSE CODE of the RELEASE message is code 16 (normal unspecified) or 
code 17 (busy condition). 



) Maintain the number of occurrences of each of the following cause codes and threshold with their 
corresponding adjustable threshold. An alarm is declared to the GUI and log file if the number of 
occurrences exceed its corresponding threshold. 

Code 1: UNALLOCATED NUMBER 
Code 3: NO ROUTE 

Code 5: MIS-DAJLLED TRUNK PREFIX 

Code 28: ADDRESS INCOMPLETE 

Code 79: SERVICE OR OPTION NOT IMPLEMENTED 

Code 81 : INVALID CALL REFERENCE 

Code 95: UNSPECIFIED INVALID MESSAGE 
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Code 97: MESSAGE TYPE NON-EXISTENT 

Code 99. 100: INVALID PARAMETER 

Code 111: UNSPECIFIED PROTOCOL ERROR 

m) A response fa RELEASE COMPLETE message) must follow a RELEASE message w„hin 
the predefined tune period plus a processing delta time. 

ui) Check for INVALID CIC RELEASE patterns - This test analyzes the CIC release patterns of 
each trunk and identifies any non-random releasing of consecutive CICs of a trunk An 
adjustable number of consecutive CICs released are identified as an INTRUSION. 

b) Release Complete - Upon reception of a RELEASE COMPLETE ISUP message, the followme tests are 
performed. An alarm is declared to the GUI and log file if any of the following condit.ons are FALSE. 

° r rfp^ p rSS;^" " mKSage WM PreV ' 0USiy de,CCted 00 sa ™ "a" " the 

RELEASE COMPLETE message. 

ii) Verify that a BLOCK message was previously detected on the same link routed in the 
opposite direction (OPCs and DPCs are reversed) of the RELEASE COMPLETE messaee 
The same direcnon indicates possible RESET inserted at far-end. 

c) Group Reset - Upon recepnon of a GROUP RESET ISUP message, the following tests are performed ^ 
alarm is declared to the GUI and log file if any of the following conditions are FALSE: 

i) Verify that at least two (2) consecutive GROUP RESET messages are detected on the same 
link in the same direcnon (OPCs and DPCs are the same). 

ii) The second message must follow the first GROUP RESET message within a five (5) second 
time period plus a processing delta tune. 

d) Reset - Upon recepnon of a RESET ISUP message, the following tests are performed. An alarm is 
declared to the GUI and log file if any of the following conditions are FALSE: 

i) Verify that no RELEASE COMPLETE message was prev.ously detected on the same link 
from the opposite direcnon (DPC and OPC are reversed) of the RESET message. 

ii) Check for INVALID CIC RESET patterns - This test analyzes the CIC reset patterns of each trunk and 
idennfies any non-random resetting of consecutive CICs of a trunk. An adjustable number of 
consecutive CICs released are identified as an INTRUSION. 

iii) A response (a UNEQUIPPED message) must follow a RESET message within the predefined 
time period plus a processing delta nme. 

e) Group Blocking - Upon reception of a GROUP BLOCKING ISUP message, the follow™ tests are 
performed. An alarm is declared to the GUI and log file if any of the following conditions are FALSE: 

i) Verify that at least two (2) consecutive GROUP BLOCKING messages are detected on the 
same link in the same direcnon (OPCs and DPCs are the same). 

ii) The second message must follow the first GROUP BLOCKING message within a five (5) 
second time period plus a processing delta rime. 

f) Block - Upon reception of a BLOCK ISUP message, the following tests are performed. An alarm .s 
declared to the GUI and log file if any of the following conditions are FALSE: 
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0 Verify «ha. no UNBLOCK ACKNOWLEDGE message was previously detected on the same 

I ° PP0S " C CCn ° n (DPC 8nd 0PC are rcvened > withu5 (15) seconds of 

-the BLOCK message. 

.i) Check for INVALID CIC BLOCKING patterns - This test analyzes the C1C block patterns of each 
trunk and identifies any non-random blocking of consecutive QCs of a trunk. An adjustable number 
of consecunve CICs released are identified as an INTRUSION. adjustable number 

g) Block Acknowledge - Upon reception of a BLOCK ACKNOWLEDGE ISUP message, the follow™ tests 
are performed. An alarm is declared to the GUI and log file if any of the following cond.nons are FALS E 

.) Verify that a BLOCK or a GROUP BLOCK message was previously detected on the same 
link from the opposite direction (DPC and OPC are reversed). 

li) A response (a UNBLOCK message) must follow a BLOCK ACKNOWLEDGE messaee 
within a five (5) minute time period plus a processing delta tune. 

h) Group Block Acknowledge - Upon recepnon of a GROUP BLOCK ACKNOWLEDGE ISLT messaw 
contowreTA K LSE:^ 0rTnCd ' ** ^ " * ^ ^ '° 8 °* * ° f ^ 

i) Venfy that a BLOCK or a GROUP BLOCK message was previously detected on the same 
link from the opposite direction (DPC and OPC are reversed). 

ii) A response (a UNBLOCK message) must follow a GROUP BLOCK ACKNOWLEDGE 
message within a five (5) minute time period plus a processing delta tune. 

0 2tSt n T L °^ T ** f ° U0W,n8 tKtS * ^ M A" "i™ is 

declared to the GUI and log file if any of the following conditions arc FALSE: 

i ) Verify that a corresponding BLOCK ACKNOWLEDGE or a GROUP BLOCK 

ACKNOWLEDGE message was previously detected on the same link from the opposite 
direction (DPC and OPC are reversed) with the following time restricts: 

•i) No UNBLOCK message should not be received within fifteen (15) seconds of the BLOCK 
ACKNOWLEDGE message. 

in) The UNBLOCK message should be received within five (5) minutes of the BLOCK 
ACKNOWLEDGE message 

j) Unblock Acknowledge - Upon reception of an UNBLOCK ACKNOWLEDGE ISUP message the 
following tests are performed. An alarm is declared to the GUI and log file if any of the following 
conditions are FALSE: 6 

.) Verify that an UNBLOCK or GROUP UNBLOCK message was previously detected on the 
same link from the opposite direction (DPC and OPC are reversed). 

k) Unequipped Circuit - Upon reception of an UNEQUIPPED CERCUIT ISUP message, the following tests 
arc performed. An alarm is declared to the GUI and log file if any of the following conditions are FALSE: 

i) Verify that a RELEASE. RESET. GROUP RESET, BLOCK or GROUP BLOCK message 
was previously detected on the same knk from the opposite dirccuon (DPC and OPC are 
reversed). 



85 



SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 



PCT/US99/17408 



APPENDIX C 
SOFTWARE DESIGN DOCUMENT 



ii) Check for INVALID UNEQUIPPED CIRCUIT CIC patterns - This test analyzes the unequipped CIC 
patterns of each trunk and identifies any non-random blocking of consecutive CICs of a trunk. An 
adjustable number of consecutive CICs released are identified as an INTRUSION. 

I) Circuit Query - Upon reception of a CIRCUIT QUERY ISUP message, the following tests are performed. 
An alarm is declared to the GUI and log file if any of the following conditions are FALSE: 

i) Verify that no RELEASE COMPLETE message was previously detected on the same link 
from the opposite direction (DPC and OPC are reversed) of the CIRCUIT QUERY message. 
Also, that the CIRCUIT QUERY message is not within a five (5) second period of the 
RELEASE COMPLETE message. 

Network Analysis 

This section deals with a periodic analysis of the network as a result of the message flow and its effect of 
that network. 



a) If a link is prohibited or restricted, as a result of a TRANSFER PROHIBIT or a TRANSFER 
RESTRICT MTP message, the following tests are performed, but only if the link to the 
desnnanon point code, referred to by the a TRANSFER PROHIBIT or a TRANSFER 
RESTRICT MTP message, is being monitored. 

i) verify that no traffic (of any protocol) is detected on the link to the destination point 
code, specified by the TRANSFER PROHIBIT or a TRANSFER RESTRICT MTP 
message. 

ii) verify that no ISUP messages are detected to and from the node corresponding to the 
destination point code specified by the TRANSFER PROHIBIT or a TRANSFER RESTRICT 
MTP message. 

b) Node Cluster unavailability activity is monitored. Maintain and threshold the numbeT of occurrences 
of the following: 

i) number of clusters down (network total). 

ii) number of clusters down by destination. 

iii) number of node down by destination. This is incremented with each node and cluster 
TRANSFER PROHIBIT or a TRANSFER RESTRICT MTP message. 



c ) Check for INHIBIT TIMEOUT VIOLATION 



Linkset Identifier Naming Convention 

This section outlines the NOC's linkset identifiers for each linkset in GTE's SS7 network. The 8-digit 
identifiers are assigned using the following convention: 



1 . I st Character - Link Type 



a) A - A links from SP/SSP/SCP to an STP pair 

b) B - B links between non-mated STPs on the same level (peers) 

c) C - C links between STPs in a mated pair 

d) D-D links between non-mated STPs on different levels 

e) local and regional pairs) 

0 E - E links from SP/SSP to an additional STP 
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g) F - F links between STPs/SSPs (not connected to STPs) 

h) X - Test links 

2. 2nd Character - Link Destination 



a) 


C 


- Mated STP 


b) 


G 


- Gateway 


c) 


I- 


Independent Company 


d) 


L- 


• Another LEC STP 


e) 


M 


- Mobile/Cellular 


0 


N 


- Non-mated STP 


g) 


P- 


SCP 


h) 


Q- 


■ AINSCP 


') 


R- 


RBOCSTP 


J) 


S- 


SSP Access Tandem Switch 


k) 


T- 


Operator Services SSP switch 


0 


U- 


SP/SSP End Office 


m) 


X- 


MGTS (test links) 


n) 


z- 


Protocol Converter 



3. 3rd, 4th, 5th characters (identifies the GTE STP): 



000 


LNCLILXC01W 


012 


tVlXlVllN v_, AJVl i y w 


001 


BLTNILXD01W 


013 


DRHMNCXF19W 


002 


MRHDKYXA 1 9 W 


014 


FTWYINXA02W 


003 


LXTNKYXA 1 1 W 


015 


GRRTINXA01W 


004 


TAMPFLXA00W 


016 


MARNOHXC01W 


005 


CLWRFLXA001 


017 


DLWROHXA01W 


008 


OCQNVAXA 1 9 W 


018 


MRFDWTXAO 1 W 


009 


MNSSVAXA19W 


019 


WAUSWTXAOIW 


010 


ERIEPAXM01W 


020 


MSKGMIXK01W 


011 


EDNBPAXE01W 


021 


THRRMDCT01W 


400 


OFLNMOXA01W 


510 


BVTNORXBOOW 


401 


WNVLMOXA01W 


511 


TGRDORXAOOW 


402 


OFLNMOXA02W 


512 


PNHoracooow 


403 


WNVLMOXA02W 


513 


wpHumoooow 


500 


SNMNCAXPOOW 


514 


DCSNTXXA0IW 


501 


ONTRCAXPOOW 


515 


BYTWTXXA01W 


502 


DNTNTXXA01W 


516 


LNBHCAXP00W 


503 


IRNGTXXAOIW 


517 


ONTRCAXP01W 


504 


BOTHWAXB01W 


518 


SANGTXXA01W 


505 


EVRTWAXAOOW 


519 


BWWDTXXA02W 


506 


PLSPCAXGOOW 


520 


SNMNCAXP01W 


507 


INDICAXGOOW 


521 


LNBHCAXP01W 
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508 SNBBCAXFOOW 524 EVRTWAXA06W 

509 SNTMCAXFOIW 525 BOTHWAXB06W 
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Overview 



The f0,I °*n«Jtter Inputs are usedto influence the analysis 



Delation of either KJS« AW serv.ces as the mode of analvs ls 

n) The node cnticaliry calculations are directly effected- 

a) determines the SCP node criticaJirv for SO>, ™. ~ n -a * 
POTS only specified) °' considered *hen 

b) the rollup of numbers of nodes gatmng access via each STP for a 
particular service Ior 3 

b) Designation of specific SSP(s) of particular importance- 

0 Z°*™£T te ^ » ^ ^ *«ch may have VIP comers 
») effects the SSP node criticality only 

The^wtng assumptions and simplifications have been mcorporated mto the Vulnerab.hty 
a) aHTest Lmksets have been removed from the database (Linkset Ids = XX = MOTS Test 
C-Unksets have been removed from the database Linkset Ids = CO 

i) Mobile SSPs (Linkset Ids = AM ) 
u) other LEC SSPs (Linkset Ids = AL ) 



b) 
c) 



LINKS 

Physical-media-rvp *- 

• ALL links will = FIBER 
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Media Type 


Functional 
Media 


fiber 


2 


microwave 


5 


satellite 


6 


coax 


9 











Phvsical-media-provider : 



Transmission Provider 


Provider 




Vulnerability 




Ranking 


GTE 


1 


AT&T 


1 


Sprint 


2 


MCI 


4 


Ameritech 


5 


Bell South 


3 


Southwestern Bell 


4 


Bell Atlantic 


4 


US West 


6 


Delta Communications 


8 


NTS Communications 


8 


PTI Communications 


8 


Norlite 


8 


Others 


9 



Functional-services : (attack desirability based on user scenario- USER INPUT ). 



Service Type 


Location 


rank 


E80OCA 


SNMC/LNBH 




E800FW 


FTWN/GRRT 




CRS 


DNTN/IRVG 




INCONTACT 


TMPA/CLWR 




LEDB CNAM 


FTWN/GRRT 





Funcrional-Capacity-%-Utilizanon 



% Utilization 


Functional 




Capacity 


0-<5 


I 


S-<10 


3 


10-<15 


5 


15- <20 


7 


20- <25 


8 


>=25 


9 
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Functional-capacity-% internally generated 



% Internally 
Generated 


rank 


0-25 




25-50 




50-75 




75-100 





Functional-security -encryption: 

• If the link is encrypted, then the overall Security Ranking = 1 (no other influences 
Security) 



to 



type 


Security 


encrypted 


1 


not encrypted 


null 



Funcrional-secunty-screening: 

Currently screening ALL on EXTERNAL links.(far end Pent Code 



Point Code Screening 


Logic 


Security 




Screening 


Screening 



Network and Cluster and Member 



message class 



Point Code Screening 


Logic 
Screening 


Security 
Screening 


NONE 


ANY 


9 









Point Code Screening 


Logic 
Screening 


Security 
Screening 


NONE 


ANY 


9 


Network only 


none 


8 


Network and Cluster 


none 


7 


Network and Cluster and Member 


none 


6 


Network only 


message class 


7 


Network and Cluster 


message class 


6 


Network and Cluster and Member 


message class 


5 


Network only 


message type 


6 


Network and Cluster 


message type 


4 


Network and Cluster and Member 


message type 


3 



Logical-number-LinksPerLinkset: 
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Note: .f data becomes ava.lable on automat.c alt routing and multiolc Linkser* , k 



# of Links 


rank 


1 


8 


2 


4 


3 


3 


4 


2 


>=8 


I 



Attribute Rglatinn thiDS (Algorithm^ 

Physical-media-rvpc && Phvsical-Media-providcr 



Media Type 


Physical Media-Access 
Rank 


any 


Media Type 


Fiber 


Fiber «- (Provider Rank • 
0.50) 


microwave 


microwave ♦ (Provider 
Rank • 0.25) 


coax 


coax f (Provider Rank • 
0.25) 


satellite 





Funcrional-Services-Miilrip lf 



Service 

ISUP 
OMAP 



E80O 
E91 1 



&& Service 



Calling Card 



LNP 

Remote Call Fwd 



VPN 

Calling Card 



OMAP 



Calling Card 



&& Service 



VPN 



may use a formula such as: 

POTS only Functional Service = 5 

1 service only = Service Ranking 

2 non-cntical (3 or 4) = most critical +1 
M && L = M 
M && M = M + 1 
M &.& H = H 

1 non-critical && 1 critical = critical + 1 (max = 10) 

2 crirical (8 or 9) = 10 

3 or more non-critical = most crirical + 2 



Ranking 



8or9 



10 



4 or 5 



Comment 



3 svc. 1 enncal 



2 enncal 



2 non-critical 



92 



SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 PCT/US99/17408 

APPENDIX D 

VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS 
LSTP-B-Links to non-GTE = POTS only 

• Functional-Services && %Utilization by Service 



Service 


&& % Traffic 
used by Service 


=» Ranking 


E911 


< 10% 


2 or 3 


E911 


>= 10% 


8or9 









• E91 1 traffic >10% of total Utilization is considered high risk 

• Functional Capacity && %-Utilization && Loadshare Links: 

• high &Utilization is far more serious on links with only 1 loadshare link; whereas, high 
%Utilization links with numerous loadshare links become have the vulnerability reduced 
(ideally in a 1/N relationship). 

• Since Functional Capacity Ranking is = %-Utilizarion Ranking at this point, then the 
multiplicity of Loadshare Links will only act to reduce the Functional Capacity Ranking... 



% Utilization 


# of Links Rank 


Functional 


tota 


Rank 




Capacity 




1 


1 


Funct Capacity - 3 




1 


2 


Funct Capacity - 2 




1 


4 


Funct Capacity - 1 




1 


8 


Funct Capacity 




3 


1 


Funct Capacity - 3 




3 


2 


Funct Capacity - 2 




3 


4 


Funct Capacity - 1 


2 


3 


8 


Funct Capacity 


3 


5 


I 


Funct Capacity - 3 


2 


5 


2 


Funct Capacity - 2 


3 


5 


4 


Funct Capacity - 1 


4 


5 


8 


Funct Capacity 


5 


7 


1 


Funct Capacity - 3 


4 


7 


2 


Funct Capacity - 2 


5 


7 


4 


Funct Capacity - 1 


6 


7 


8 


Funct Capacity 


7 


8 


1 


Funct Capacity - 3 


5 


8 


2 


Funct Capacity - 2 


6 


8 


4 


Funct Capacity - I 


7 


8 


8 


Funct Capacity 


8 


9 


1 


Funct Capacity - 3 


6 


9 


2 


Funct Capacity - 2 


7 


9 


4 


Funct Capacity - 1 


8 


9 


8 


Funct Capacity 


9 



• Phvsical-Connectivitv-Intemal && %Utilization && %GeneratedExtemal: 

• Internal Connectivity = GTE for Transmission Provider 

• % Generated External = 0% for Far point code = GTE =240 
(default of Tranmission Provider = Far Node Owner) 
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% Generated 


= Functional 


External 


Capacity 


0 


Funct Capacity 


I - 10 


Funct Capacity + 0.5 


11-20 


Funct Capacity + 1 


21-30 


Funct Capacity + 1.5 


31-40 


Funct Capacity +■ 2 


41-50 


Funct Capacity -t- 2.5 



• Phvsical-Connectivitv-External && %Utilization && %Gcnerated-Extemal: 

• External Connectivity = NOT GTE for Transmission Provider 

• % Generated External = 50% for Far point code NOT= GTE NOT=240 
(default of Tranmission Provider = Far Node Owner) 



% Generated 
External 


<= Functional 
Capacity 


0 


Funct Capacity 


1 - 10 


Funct Capacity + I 


11-20 


Funct Capacity + 2 


21-30 


Funct Capacity + 3 


31-40 


Funct Capacity + 4 


41-50 


Funct Capacity + 5 



• Functional-Capacity && Security-Monitoring: 

• Even though a link may be monitored, When a link is monitored, the Capacity ranking is 
decreased (less Vulnerability) but the degree to which the ranking is decreased still follows 
the '->gic that it is easier to hide intrusion messages in a higher occupancy link. The increase 
of traffic load and performance parameters on the link by inserted message traffic is again, 
less significant on a higher occupancy link, (where the occupancy is represented within the 
Capacity ranking - the higher Occupancy the higher the Capacity ranking ) 

• Whether Monitoring exists or not is influencing the Capacity (% Utilization) ranking 



Functional 


&& Monitoring 


= New Functional 


Capacity 




Capacity 


any 


false 


Func Capacity 


L 


true 


Func Capacity 


M 


true 


Func Capacity - 2 


H 


true 


Func Capacity - 1 



• Functional-Security-Screening && Functional-Securitv-Momtoring: 



Screening Rank 


&& Monitoring 


= Security 


any 


false 


Screening 


1,2,3,8,9,10 


true 


Screening - 1 


4,5,6,7 


true 


Screening - 1 
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• Functional-Services && Functional-Security: 



Services Rank 


&& Monitoring 


= New Service Rank 


any 


false 


Service Rank 


1 or 2 or 3 


true 


Service Rank 


4 


true 


Service Rank - (Security 
Rank • 0.75) 


5 


true 


Service Rank - (Security 
Rank • 0.5) 


6 


true 


Service Rank - (Security 
Rank • 0.25) - 


7 or 8 or 9 


true 


Service Rank 



• Service Ranking is influenced by Security only in the middle rankings 

Link Level Relationships 

• When physical access difficult then Vulnerability is not very influenced bv other factors: 

• Physical Media Access <= 3 && Functional Services 8,9. 10 && Functional Capacity 8,9, 10 
= Physical Media Access +1 

• Physical Media Access <= 3 && any other influences 
Link Vulnerability = Physical Media Access 



• When physical access is mid-ranee Vulnerability is most heavily influenced by Security: 

• Physical Media Access >=4 , <=7 
&& Functional Services 8,9,10 

&& Functional Capacity 8,9,10 

&& Security 1,2,3 

Link Vulnerability = Security +■ 1/2 

• When physical access is mid-range and Security is also mid-rangeVulnerabilitv is influenced bv 
Functional Services and Functional Capacity equally: 

• Physical Media Access >=4 , <=7 
&&Security >=4 , <=7 

Link Vulnerability = 



Functional 
Services 


Functional 
Capacity 


Vulnerability Total 


H 


H 


Average of Scores 


H 


L 


Average of Scores 


L 


H 


Average of Scores 


L 


L 


Average of Scores 


M 


M 


Average of Scores + 1 


M 


H 


Highest Score 


M 


L 


Highest Score 
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L 


M 


Highest Score 


H 


M 


Highest Score 



• When physical access is mid-range and Security is high-range Vulnerability is influenced bv 
Functional Services and Functional Capacity equally but further degraded by poor Security: 

• Physical Media Access >=4 , <=7 
&&Security >=8 . <=10 
Link Vulnerability = 



Security 


Functional 
Services 


Functional Capacity 


Vulnerability Total 


H 


H 


H 


Average of Scores - 1 


H 


H 


L 


Average of Scores - 1 


H 


L 


H 


Average of Scores - 1 


H 


L 


L 


Average of Scores - 1 


H 


M 


M 


Average of Scores - 2 


H 


M 


H 


Highest Score 


H 


M 


L 


Highest Score 


H 


L 


M 


Highest Score 


H 


H 


M 


Highest Score 



• When physical access is high-range Vulnerability is not influenced very heavily but is modified as follows: 



Security 


Functional Services 


Functional Capacity 


Vulnerability Total 


H 


H 


H 


Physical Access Score 


H 


H 


L 


Physical Access Score 


H 


L 


H 


Physical Access Score - 1 


H 


L 


L 


Physical Access Score - 2 


H 


M 


Ni 


Physical Access Score- 1 


H 


M 


H 


Physical Access Score 


H 


M 


L 


Physical Access Score - 1 


H 


L 


M 


Physical Access Score - 1 


H 


H 


M 


Physical Access Score 










M 


H 


H 


Physical Access Score 


M 


H 


L 


Physical Access Score - 1 


M 


L 


H 


Physical Access Score - 1 


M 


L 


L 


Physical Access Score - 3 


M 


M 


M 


Physical Access Score- 2 


M 


M 


H 


Physical Access Score- 1 


M 


M 


L 


Physical Access Score - 2 


M 


L 


M 


Physical Access Score - 3 


M 


H 


M 


Physical Access Score -1 










L 


H 


H 


Physical Access Score - 1 


L 


H 


L 


Physical Access Score - 2 


L 


L 


H 


Physical Access Score - 3 


L 


L 


L 


Physical Access Score - 3 
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M 
M 



M 
H 



Physical Access Score- 2 



Physical Access Score- I 



M 
L 



L 
M 



Physical Access Score - 2 



_L_ 
L 



Physical Access Score - 3 



H 



M 



Physical Access Score -2 



Correlation of the Node Criticality Ranking into the overall Link Vulnerability: 

• The inherent vulnerabilities of each link should be reconciled with the desirability of 

intruding upon the link to gain access to the most desirable node in the network Ideally it IS 
more desirable to intrude onto a link directly connected to the most desirable node Hence 
the further away from the most desirable node the less desirable (less vulnerable) the link ' 
becomes. 



Locarion-Number-transfers-to-crirical-node: (Critical Node must first be determined) 



Number of Hops 


Ranking 


0 (direct connect) 


Vulnerability 


1 


Vulnerability - 1 


2 


Vulnerability - 3 


3 


Vulnerability - 6 


4 


Vulnerability - X 


5 


Vulnerability - Y 



this ranking uses the concept that the further from the intrusion occurs from the desired 
the less likely the attack has at success due to routing/ screening, etc. 



Node Attributes 

Default Node Rankings: 



Node Type 


Ranking 


ST? 


7 


SSP Tandem 


6 


SSP End Office 


3 


SSP TOPS 




SCP 





Node-criticalitvi 

SCP Node Criticality -{Average of Service Desirability Rankings) • I (SSPs w/ access via SCP to 
desired service) • (Normalized Node Capacity) 

• X (SSPs w/ access via SCP to desired service) = 100% since each service is 
implemented only in one place •• EXCEPT CNAME (CA and Ft Wayne) => 
need to. have routing info in place for CNAME service - East / West division 
follows. 



• when POTS is defined, the SCP Node Criticality is null 



97 

SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 



PCT/US99/17408 



APPENDIX D 

VULNERABILITY ANALYSIS ATTRIBUTES AND ALGORITHMS 

• Average of Service Desirability = Hscore of all services) / (num of services at SCP) 

• Normalized Node Capacity = XXlink occupancy for all links at node) / &link occupancy for 
all links in region ) 

Node-criticality 

STP Node Criticality: 

• is influenced by the User Input of the Critical Servtce Rankings: 

• Critical Service Ranking is used to determine SCP locations providing access to the 
(N) highest ranked services) - 

• Determining Most critical SCP must account for combined ranking(s) of the (each) 
service accessed by the SCP (Average of Service Desirability Rankings at that SCP) 

• Critical SCP Location is then used to determine the Number of Hops to the Critical 
Service from each STP 

• Number of Hops to the Crural Service is used to determine the STP Node Criticality 

• STP Node Criticality = 

Lr*.- " ( Service Ranking * I^SSPs ^ ) * Normalized Node Occupancy^ 
/ ( £ lU (SSPs) * Number of Hops to Critical SCP ) 

. POTS STP Node Criticality = I (SSPs w/ access via STP to desired service) * 
(Normalized Node Capacity) 

• Normalized Node Occupancy,^ = S^toflink occupancy for all links at node) 
/ (Total Link Occupancy),^*,. 

. Average of Service Desirability = I(score of all services) / (number of services via STP) 
/ (number of STPs at same number of hops from critical service) 

• when POTS is defined, number of hops replaced by number of STPs at same 
level in network (if node is LSTP then divide by number of LSTPs connected to 
parent RSTP; if node is RSTP then divide by number of RSTPs ) 

• determining the Number of Hops to Critical Service may be determined by 
starting at the location of the Critical SCP and working backward into the 
network traversing each chain of links back through each RSTP to each LSTP- 
as each STP is encountered, the count for the number of hops is to be noted for 
each STP. 

• for LSTPs: I SSPs are those SSPs directly connected to STP 

• for RSTPs Z SSPs are all SSPs connected to the subtended LSTPs 



Node-criticalirv (cont'd): 

SSP Node Criticality = Default Node type Score • Customer Importance * Normalized Node Capacity 

• Customer Importance = ranking input by user to indicate a high priority user homed to 
specific switch(es) 
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' a^ISkl't^rcgion ) CaPadty = ^ ° CCUpanCyf ° r a " links at node > ' occupancy for 



Overall Node-Criticalitv • 



Owner 


Network Code 


Node Owner 
Vulnerability 
Ranking 


Ranking 


Internal 


240 


1 


Criticality * (0.5 
• Ranking) 


AT&T 


215 


1 


Criticality + (0.5 
* Ranking) 


MCI 244 


2 


Criticality + (0.5 
• Ranking ) 


spnnt 


253 


4 


Criticality * (0.5 
' Ranking) 


Bell Atlantic 


246 


5 


Criticality - (0.5 
* Ranking) 


Bell South 


252 


3 


Criticality * (0.5 
* Ranking) 


Pacific Bell 


251 


4 


Criticality *-(0.5 
• Ranking) 


Ameritech 


250 


4 


Criticality - (0.5 
* Ranking) 


US West 


248 


6 


Criticality + (0.5 
• Ranking) 


LCI 


001-016 


8 


Criticality + (0.5 
* Ranking) 


others 




8 


Criticality + (0.5 
" Ranking) 



Capaciry-number-altemates: (how many other nodes can provide same function 
SSPs) 



in auto alt routing- ignore 



Alt Nodes Avail 


Ranking 


1 


Criticality - 2 


> I 


Criticalify - 5/6 



service 



1 same 



Security-physical: 



Access 


Ranking 


occupied <10 


Criticality - 1 


occupied 10-15 


Criticality 


occupied >15 


Criticality + 1 (too 
many people to 
control) 


Unoccupied 


Criticality ■*■ 3 
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Security-observation: 





(max = 8) . 


remote private 


Critical ity 


remote public 


Critical iry + 2 




Observation 


Ranking 


exists 


Criticality - 5 


not exist 


Criticaliry 



• Physical security alarming monitoring: access, door open, logon reporting. 
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MTP: 



Changeover (TLMESTAMP. LINKJD, DIRECTION, OPC, DPC. SLC) 

• Threshold number of occurrences 

• LINK_NEAREST_NEIGHBOR (check OPC and DPC are on collected link) 

Changeover Ack (TTMESTAMP. LINK ID, DIRECTION, OPC. DPC, SLC) 

• CORRELATE_TO_CHANGEOVER || CORRELATETOEMERCHANGEOVER (noprev.ous 
Changeover indicates Changeover requested from another source) 

Emergency Changeover Ack (TTMESTAMP, LINKJD, DIRECTION, OPC. DPC. SLC) 

• CORRELATE_TO_CHANGEOVER (no previous Changeover indicates Changeover requested from 
another source) 

Emergency Changeover (TTMESTAMP, LINK_ID, DIRECTION, OPC, DPC, SLC) 

• Threshold number of occurrences (very low ) 

• LINKNEARESTNEIGHBOR (check OPC and DPC are on collected link) 



Transfer Prohibit (TTMESTAMP, LINK_ID, DIRECTION. OPC, DPC, DESTINATION) 

• Node and Cluster cases 

• LINK_NEAR£ST_NEIGHBOR (check OPC and DPC are on collected link) &&OPC STP (onlv sent 
from STPs) 

• CORRELATE_TO_DESTTNATION (if DESTINATION point code is monitored) 

• check DESTINATION point code is 1 removed from OPC node 

. CORRE LATE_TO_CHANGEOVER (check link to the DESTINATION point code for : 

• previous Changeover 

• || LSSU 

• HFISU) 

• CORRELATE JTO_LINK_INHIBrT (outgoing case: check link to the DESTINATION potnt code 
for receipt of Link Inhibit from an adjacent STP referencing a link toward particular node) 

• CORRELATE_TO_TRANSFER_PROHIBIT ( outgoing case: check link to the DESTINATION 
point code for receipt of Transfer Prohibit from an adjacent STP) 

• case B or D-Iinks CHECK_OPCs 

• Scenario: Once the STP sends a Transfer Prohibit or Transfer Restrict message 
additional message traffic from the DESTINATION node should not occur. Therefore, 
any messages to/from (especially from) the STP with the OPC = DESTINATION 
indicates that the Transfer message probably was not sent by the STP and may have been 
inserted on the link. 

{ 

• if OPC or DPC of any message = DESTINATION then ALARM 
} 

Transfer Restrict (TTMESTAMP, LINK_ID, DIRECTION, OPC, DPC, DESTINATION) 

• Node and Cluster cases 

• LINK_NEAREST_NEIGHBOR (check OPC and DPC are on collected link) && OPC STP (onlv sent 
from STPs) ~ 

• CORRELATE_TO_DESTTNATION (if monitored) 

• check DESTINATION point code is 1 removed from OPC node 

• CORR£LATE_TO_CHANGEOVER (check link to the DESTINATION point code for : 

• previous Changeover 

• || LSSU 

• || FISU) 
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• CORRELATE_TO_LINK_ INHIBIT (outgoing case: check link (o the DESTINATION point code 
for receipt of Link Inhibit from an adjacent STP referencing a link toward the DESTINATION 
node) 

• CORRELATE_TO_TRANSFER_PROHIBIT ( outgoing case: check link to the DESTINATION 
point code for receipt of Transfer Prohibit from an adjacent STP) 

• case B or D- links CHECK_OPCs 

• Scenario: Once the STP sends a Transfer Prohibit or Transfer Restrict message 
additional message traffic from the DESTINATION node should not occur. Therefore, 
any messages to/from (especially from) the STP with the OPC = DESTINATION 
indicates that the Transfer message probably was not sent by the STP and may have been 
inserted on the link. 

{ 

• if OPC or DPC of any message = DESTINATION then ALARM 
} 

• Signaling Route Set Test (T10 expires) (TIMESTAMP, LINK_ID, DIRECTION. OPC. DPC, DESTINATION) 

• Scenario: When an STP sends a Transfer Prohibit or Transfer Restrict message the receiving 
node will initiate a Test Message transaction over the same link as the Transfer message. 
Therefore a Test Message should always be preceded by a Transfer message. Once the STP 
sends a Transfer Prohibit or Transfer Restrict message additional message traffic to or from 
the DESTINATION node being referred should not occur. Also, if a Transfer Allowed is the 
immediate response to the 1" Test Message then this may indicate that the Test Message may 
have been the result of an inserted Transfer Prohibited or Transfer Restricted message at the 
Test Message OPC node. 

• COUNT_CONSEaJTTVE 

count the number of consecutive Test Messages which did not receive a Transfer Allowed 
response 

• CO RRE LATETO TRANSFER 

{ 

• case: Test for Prohibit 
{ 

• CORRELATE_TO_TRANFER_PROHIBrT(if a previous Transfer was not SENT by 
STP re: Destination, indicates far-end got bogus Transfer) 

> 

• case: Test for Restrict 
{ 

• CORRELATE_TO_TRANFER_RESTRICT (if a previous Transfer was not SENT by 
STP re: Destination, indicates far-end got bogus Transfer) 

) 

• if FAIL of BOTH correlations then ALARM 
} 

• Transfer Allowed (TIMESTAMP, LINKID, DIRECTION, OPC, DPC, DESTINATION) 

• CORR£LATE_TO_TRANSFER 

• Scenario: If a Transfer Prohibit or Restricted message in the same direction, did not precede 
a Transfer Allowed message this may indicate that a Transfer Prohibit or Restricted message 
was inserted at the Allowed OPC node on a different link 

{ 

• if FAIL then ALARM 

I 

• CORREL ATE_TO_ 1 "_TEST MESSAGE 
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• Scenario: If a Transfer Allowed is the immediate response to the 1" Test M««„, *. l 
Prohtbtted or Transfer Restncted message at the Test Message OPC node 



if Test Message counter = 1 then ALARM 

Threshold Number of occurrences of Transfer Allowed reply to I s Test Message 



Link Umhibir (TIMESTAMP, LINK [D. DIRECTION. OPC DPC SL Ci 

• CORRELATE TO INHIBIT ACK T14 * ' 
< " ~ 

• if occurs before Ack or Denied or Timeout 

} then =>ALARM (possible Uninhibit insertion or Response to inserted Link Inhibit) 

• CORRELATE TO REMOTE LINK TEST 

{ 

• if no Remote Link Test || if response to Local Link Test 

( • => ALARM (possible Response to mserted Link Inhibit from different link or Lninh.b.t msencd) 

• Threshold number of rimes Link Uninhibit is response to 1" Test cycle 
Link Force Unihibit (TIMESTAMP, LINK ID, DIRECTION OPC DPC SI n 

{ " " 

• if no Local Link Test || if response to Remote Link Test 

^ • -> ALARM (possible Response to inserted Link Inhibit from different link or Uninhibi, u^ened) 

• Threshold number of times Link Force Uninhibit is response to 1 - Test cycle 

Link Inhibit (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC SLC 

• Threshold number of occurrences within Timepen'od 

• CHECK_FOR_PATTERNS SLC 

• LINK_N-EAREST_NEIGHBOR (check OPC and DPC are on collected link) 

• case: LOCAL_INHIBIT (Linkjnhibit sent from node) 

• while T14 not expired && (Inhibit Ack or Inhibit Denied ) not received 

• If Uninhibit or Inhibit sent: 
then => ALARM 

( 

• elsewhile Utiinhibit not sent nor Forced_Uninhibit received: 

• The Inhibit was accepTed and we are within the Test Message cycle 

• Scenario: If a Local Inhibit message was inserted we should see the ACK 
from the Remote node. Then when the T20 expires, no Local Inhibit Test 
message will be sent. However, at the remote end, T21 expires and a 
Remote Inhibit Test message will be sent to the local node. Since the Local 
Node « not in the Inhibit mode, the Local node will respond with an 
Uwnhibu message. This is the indicator that the original Link Inhibit 
message was inserted (or passed through the local node) to the Remote 
node. 

{ 
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INTRUSION DETECTION ALGORITHMS 

• when T20 expires: check for lack of Local Inhibit Test 
AND 

• when T2 1 expires: check for Remote Inhibit Test received followed by Uninhibit 
sent 

• => soft alarm for 1 " T20/T2 1 cycle 

• => threshold for multiple occurrence of I" cycle Uninhibit 



when T20 expires: check for Local Inhibit Test sent followed by no reaction 
received (still remote inhibited) 

when T2 1 expires: check for no action received (now remote UNinhibired) 
when T20 expires 2- time check for Local Inhibit Test sent followed by 
ForcedUninhibit received 

T ( RCm ° te n0de $houJd ^ sem a Forced Uninhibit if it initiated 

the ^inhibit procedure. Since it only sent a Forced_Uninhibit as a response to the 
Local Inhibit test this may indicate the Remote node may be toggled back to an 
Uninhibited mode via alternate path) 



I 
I 

case: REMOTE_INHD3 FT (LinJcJnhibit received by node) 
• while T14 not expired && Inhibit Ack not sent 
• if Uninhibit received: ALARM 



elsewhile Forced_Uniabibit not sent || Uninhibit not received: (the INHIBIT has been accepted) 
• (Same conditions as LOCAL CASE only reverse sent and received designators) 



Link Inhibit Ack (TIMESTAMP, LINKJD, DIRECTION, OPC, DPC, SLC) 

• Scenario: no action is ialcen at the Local node when an unsolicited ACK is receded (due to 
an inserted Link Inhibit => TI .1 1 1 .4-38: no action 

• LINK_NEAREST_NEIGHBOR (check OPC and DPC are on collected link) 

• CORRELATE _TO_rNHIBIT 

Link Inhibit Denied (TIMESTAMP, LINK ID, DIRECTION. OPC, DPC SLC) 

• LINK_NEAREST_NEIGHBOR (check OPC and DPC are on collected link) 

• CORRELATE _TO_INHIBITT 14 

• Threshold Consecutive Attempts 

{ 

• if >2 then ALARM 

} 

Link Local Test Signal (T20 expires) (TIMESTAMP, LINK_ID, DIRECTION OPC DPC SLC) 

• CORRELATE _TO_INHIBIT_T20 (no Inhibit sent is ALARM) ' 

• if 1 st Test && Forced Uninhibit received: soft ALARM 

Link Remote Test Signal (T21 expires) 

• CORRELATE _TO_INHIBIT_T2 1 (no Inhibit received is ALARM) 

• if 1 st Test && Uninhibit received: soft ALARM 
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Transfer Controlled (congestion throttling) 

' Jr 0 rsmt R£ST - NE,GHB ° R (ChCCk *" 0 " COl,CC,ed ,,nk) && OPC - S ™ <«* - 



• Signaling Route Set Congestion Test (T15/ TI6 expires) 
• CORRELATE JTO_TRANSFER_CONT 



ISUP 

Initial Address (TTMESTAMP, LINK_rD. DIRECTION. OPC, DPC, CIQ 

• Scenario: store by CIC and TIMESTAMP use for correlation to REL Illceal IAM m «.,„. <■ 
are not a significant threat to the network from a Service Di Smp ^cS L^ZllTn 
initiated to overwhelm network resources. rupnorvUcmal aspect unless a flooding attack w 

Address Complete (TIMESTAMP. LINK_ ID. DIRECTION OPC DPC CIC) 
store by CIC and TIMESTAMP use for correlation 

Release (TIMESTAMP. LINK_CD. DIRECTION, OPC, DPC. CIC. CAUSE CODE) 

Threshold * Occurrences 

check for VaLID_DPC on link 

check for VALIDOPC on link 

check TRUNK_NEAREST_NEIGHBOR 

CORR£LATE_TO_lAM 

check CAb'SE_CODE 

• Code 1 : unallocated number 

• Code 3: no route 

• Code 5: misdialled trunk prefix 

• Code 28: address incomplete 

• Code 3 1 : normal unspecified 
{ 

• CORRE LATE_TO_ACM (ACM must occur pnor to Normal Release) 

• Code 79: service or option not implemented 

• Code 8 1 : invalid Call Reference 

• Code 95: unspecified invalid message 

• Code 97: message type non-existent 

• Code 99. 100: invalid parameter 

• Code 111: unspecified protocol error 

CHECK_FOR_PATTERNS_CIC 

. Scenario: We are looking for the possibility that an attack on tearing down calls would have a 
pattern m the voice trunk numbers under attack. This would be found by looking for non 
random patterns tn the CIC parameter of consecutive REL messages. One possibility is to 
attack stamng at low CIC numbers since calls are assigned from low to hieh 

• sequential numbering 0,1,2,3...N 

• switch specific numbering (accounting for switch specific card /shelf distributions) 

Release Complete (TIMESTAMP. LINKJD, DIRECTION OPC DPC CIC) 
CORRELATE_TO_REL || CORRELATETORESET || CORRELATE jrO_BLO 

. Scenario: RLC is poss.ble response to receiving any above. So.",f none of these messages preceded the 
KLL U,en it is an indicator that any of these messages was inserted at the RLC OPC node over a 



105 



SUBSTITUTE SHEET (RULE 26) 



WO 00/07312 



PCT/US99/ 17408 



APPENDIX E 
INTRUSION DETECTION ALGORITHMS 

different link. Furthermore, a Reset or Circuit Query response from the RLC indicates that the RLC 
was an unexpected message. This is further evidence that the RLC OPC node did not send the Release, 
Reset, or Blocking message. 

{ 

. if FAIL 
{ 

• start timer and check for RESET II CIRCUIT QUERY (possible response to out of sequence RLC received 
at unaffected xchange due to insetted BLO) 

• case: BLO sent in same direction: ALARM 

• Scenario: A Blocking message followed by an RLC observed in the same direction would occur only 
if the RLC OPC node received a Reset in a particular call state. Therefore the Reset message should 
have been observed before the BLO. If the Reset was not observed before this sequence than this 
indicates that the Reset was inserted at the RLC OPC node over a different link. 

I 

I 

. Croup Reset (TTMESTAMP. LINKJD. DIRECTION. OPC, DPC. CIC, RANGE) 

• Check for pair of Group Resets within 5 seconds 
. check for VALID OPGTJPC 

« check TRUNK_N : EAREST_NEIGHBOR 

• Threshold number of Occurrences within Timeperiod 



. Reset (TTMESTAMP, LINK_ID, DIRECTION, OPC, DPC, CIQ 

• check for VALID OPC/DPC 

. check TRUNK_NEAR£ST_NEIGHBOR 

• Threshold number of Occurrences within Timeperiod 
. CHECK_FOR_PATTERNS_CIC 

• sequential numbering 0, 1 ,2,3.. .N 

• switch specific numbering (accounting for switch specific card /shelf distributions) 

• set timer ( 1 5 seconds) and wait for Unequipped 

• CORRELATE_TO_RLC 

• Scenario: A Reset or Circuit Query response from the RLC indicates that the RLC was an unexpected 
message. This is possible evidence that the RLC was the result of an inserted Release. Reset, or 
Blocking message at the RLC OPC node over a different link. 

• Group Blocking (TTMESTAMP, LTNK_ID. DIRECTION, OPC, DPC, CIC, RANGE) 

• Check for pair of Group Blocking within 5 seconds 

• check for VALTD_OPC/DPC 

. check TRUNK_NEAREST_NEIGHBOR 

• Threshold number of Occurrences within Timeperiod 

. Blocking (TTMESTAMP, LINKJD, DIRECTION, OPC, DPC, CIC) 

. check for VALTD_OPC/DPC 

. check TRUNK_NEAR£ST_NEIGHBOR 

• Threshold number of Occurrences within Timeperiod 

• set timer (5 nun) and CORRELATE_TO_UNBLOCK (should not be held longer) 

• CHECK_FOR_PATTERNS_CIC 

• sequential numbering 0,1,2,3. ..N 

• switch specific numbering (accounting for switch specific card /shelf distributions )- 

• CORR£LATE_TO_UBLA 

• Scenario: An Blocking message sent in response to an Unblocking Acknowledgment message 
indicates that the UBLA was unexpected since the CIC was not in a Local Unblocked state. This could 
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indicate thai the UBLA was caused by an inserted Unblock to the UBLA OPC node over a different 

• Threshold number of occurrences 

Blocking Ack (TIMESTAMP, LINK INDIRECTION OPC DPC CIC) 
CORRELATE TO BLO ( fail then: ALARM) 

• Scenario: If a BLA received without seeing a previous BLO then thts indicates that a BLO mav hae h^n 
inserted at the BLA OPC node y e Deen 

Unblock (TIMESTAMP. LINK_ID. DIRECTION. OPC. DPC, CIC) 

• Scenario: The system monitors for this message primarily as indicator that some other message mav 
not be legitimate. An illegal Unblocking message in of itself would only serve to bnng CICs back ' 
INTO service prematurely; this is not perceived as a significant threat to the network 

CLEAR_BLO_TIMER 

• Scenario: a circuit should only remain in a Blocked condition for no longer than approximately 5 
minutes (usually due to maintenance actions) 

CO RRE LATETOB LA 

' **,TnA n Unb,0ckin8 m " SagC » «PO"« » a Blocking Acknowledgment message indicates 
that the BLA was unexpected since the CIC was not in a Local Blocked state. This could md.cate that 
the BLA was caused by an inserted BLO to the BLA OPC node over a different link 

• Threshold number of occurrences 

Alarm aggregate to FAIL of BLA correlation to BLO 

Unequipped Circuit (TIMESTAMP. LINK ED, DIRECTION, OPC. DPC, CIC) 

• Scenario: Unequipped response indicates that the Release, Reset or Blocking message was invalid 
since there is no circuit to reset This is not very common since it indicates that the trunk status tables 
are out of sync or that the Release, Reset or Blocking messages are coming from a surce which has no 
knowledge of the trunking status. Therefore, a low threshold on the Unequipped messaees is 
warranted. ° 

CORRELATETOREL || CORR£LATE_TO_R£SET || CORRELATE_TO_BLO 
Threshold number of Occurrences within Timeperiod per CIC (low threshold) 
CHECK_FOR_PATTERNS_CIC 
sequential numbering 0,1. 2,3. ..N 

• switch specific numbering (accounting for switch specific card /shelf distributions) 

Circuit Query (TIMESTAMP, LINK_ID, DIRECTION, OPC, DPC, CIC) 

• Scenario: Circuit Query sent as a response to a particular message (vice on a penod.c polled basts) 
indicates a loss of sync in the making status tables. This is an event which should happen 
infrequently. It could also indicate that the node sending the offending message is not legitimate and is 
attempting to perform actions which are inconsistent with the actual trunk status Alternatively 
unsolicited Circuit Queries can indicate a "fishing expedition" by someone trying to build a database 
on the network trunking. 

check for VALID_OPC/DPC 
check TRUNK_NEAR£ST_NEIGHBOR 
Threshold number of Occurrences within Timeperiod 
CORRE LATE_TO_RLC 

• Threshold number of occurrences by CIC 

• Scenario: A Reset or Circuit Query response from the RLC indicates that the RLC was an unexpected 
message. This is possible evidence that the RLC was the result of an inserted Release, Reset, or 
Blocking message at the RLC OPC node over a different link. 

CORELLATE TO I AM (assuming monitoring A-link at STP) 
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for both A-links 

' f i S;" M - D ----«~c^M.0Pc MDPC=IAM DPC „ 

• { return PASS} 

• else 

• {return FAIL: ALARM} 



• have valid ISUP trunking relationships 

• w ere collected on the proper links 

Query database for C7RTE table for Point Code eaual to «,h„ * 

• * Table Point Code - OPC (check £<^*^&£?* " ° K 

• search for record entry with. DPC 

• if found 

• { 

• case A-link; 

• { 

• Check JTurrentJLink(R£TURN LinkID) 

• ( verify A-link ID = Current Link ID) 

• } 

• case B-link: 

• { 

• Lookup_B-Link(RETURN_DPQ 

• (Query STP_C7RTE Table with DPC to obtain proper B lint- m r 
Check_Current_Link(RETURN LinkID) f ° r r ° Ute tQ DPC) 

• ( verify B-link ID = Current Link ID) 



) 



*. (R£TURN.DPC_N0T_C7RTE } (the DPC was not a vaUd ISUP SIgnaluig panner) 



clseif Table Point Code = DPC (check for C7RTE Table for DPC) 

search for record entry with OPC 

• if found 

• { 

• case A-link: 

• { 

• Check_Current_Link(R£TURN LinkID) 

• ( verify A-link ID = Current Link ID) 

• } 

• case B-link: 

• I 

• LookupB-LinkfRETURNOPQ 
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^ • ( verify B-link ID = CurTcnt Link ID) 

• else |R£TURN_OPC_NOT_C7RTE| (theOPC 



was not 



a valid ISUP signaling partner) 



else (Table Point Code did not match either OPC or DPC of message* 
{ RETURN INV ALID_PC } message) 



• SCCP UDT: 

• case: GTT = TRUE 
{ 



SSST GTE - SWITCH: ™ DPC ' ^ fcr corresponding CALLING PARTY PC 



{ return pass) 
else 

{return fail} 

> 



• case: UDT_CTT = TRUE (SSN = 0) 

• ( 

• lookup in Table IAM: enter CIC, look for previous catteetfA ™ w j , 

• where: (IAM_TTMESTAMP < REL.TIMECT^ COrres P° ndul S 
• case: REL TOWARD SSP (IAM toward STP) 

• { 

• && (DPC = IAM_OPC || IAM_DPC = STP PC) 

• if found 

• { return PASS} 

• else 

• {return FAIL ALARM } 

• } 

• case: REL TOWARD STP (IAM toward SSP) 

• { 

• &&. (OPC = IAM_DPC I I ??IAM OPr = <ttp 

• if found 

• ( return PASS) 

• else 

• {return FAIL ALARM } 



Algorithms 

• Link Level 

• error message responses 

• FSN out of sequence 

• occurrence threshold 

• thresholding on each link by message type 

• number of occurrences 

• frequency of occurrences 

• patterns of circuits (REL , BLO) 

• sequential numbering 0 12 3 N 

• patterns of links (Changeover, Transfer Prohibit/Restrict) 
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• Node Level 

• correlate messages across I inks/1 inkscts 

• look for FISU/LSSU on links (Changeover. Transfer Prohibit/Restrict) 

• look for low level outages across links-linksets 
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Claims: 

1. An apparatus for providing indications of attempted intrusion in a 
telecommunications signaling network, comprising: 

means for receiving messages related to communications in the 
5 telecommunications signaling network; 

means for applying intrusion rules to the messages in order to order to detect 
anomalies in the messages; and 

means for reporting an indication of the detected anomalies. 

2. The apparatus of claim I wherein the receiving means includes 
10 means for receiving predefined test messages. 

3. The apparatus of claim 1 wherein the receiving means includes 

means for parsing and formatting the messages as required for the application 
of the intrusion rules. 

4. The apparatus of claim I wherein the applying means includes 

1 5 means for comparing the messages with information related to a known 

protocol for the telecommunications signaling network. 

5. The apparatus of claim I wherein the reporting means includes 

means for presenting in a user interface a topological representation of a 
portion of the telecommunications signaling network. 
20 6. The apparatus of claim 5 wherein the reporting means includes 

means for presenting in the user interface indications of alarms representing the 
attempted intrusions. 

7. An apparatus for determining a vulnerability of a telecommunications 
signaling network to attempted intrusions, comprising: 
25 means for receiving rankings for particular parameters related to elements of 

the telecommunications signaling network; 

means for applying vulnerability rules to the rankings in order to determine a 

ill 
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likelihood of an attempted intrusion into the corresponding elements of the 
telecommunications signaling network; and 

means for reporting an indication of the likelihood of the attempted 

intrusions. 

5 8. The apparatus of claim 7 wherein the receiving means includes means for 
presenting a user interface for receiving the rankings. 

9. The apparatus of claim 7 wherein the applying means includes 

means for combining the rankings according to particular criteria in order 
to produce numerical results providing indications of the likelihood of the 
10 attempted intrusions relative to the corresponding elements in the 
telecommunications signaling network. 

10. The apparatus of claim 7 wherein the reporting means includes 

means for reporting a most vulnerable node and a most vulnerable link in 
the telecommunications signaling network. 
15 J i a method for providing indications of attempted intrusion in a 
telecommunications signaling network, comprising: 

receiving messages related to communications in the telecommunications 

signaling network; 

applying intrusion rules to the messages in order to order to detect 

20 anomalies in the messages; and 

reporting an indication of the detected anomalies. 

12. The method of claim 1 1 wherein the receiving includes 
receiving predefined test messages. 

13. The method of claim 1 1 wherein the receiving includes 

25 parsing and formatting the messages as required for the application of the 

intrusion rules. 

14. The method of claim 1 1 wherein the applying includes 
comparing the messages with information related to a known protocol for the 
telecommunications signaling network. 

30 15. The method of claim 1 1 wherein the reporting includes 

1 12 
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presenting in a user interface a topological representation of a portion of 
the telecommunications signaling network. 

1 6. The method of claim 1 5 wherein the reporting includes 
presenting in the user interface indications of alarms representing the 

5 attempted intrusions. 

17. A method for determining a vulnerability of a telecommunications 
signaling network to attempted intrusions comprising: 

receiving rankings for particular parameters related to elements of the 
telecommunications signaling network, applying vulnerability rules to the rankings 
i o in order to determine a likelihood of an attempted intrusion into the corresponding 
elements of the telecommunications signaling network; and 

reporting an indication of the likelihood of the attempted intrusions. 

1 8. The method of claim 1 7 wherein the receiving includes 

presenting a user interface for receiving the rankings. 
15 19. The method of claim 17 wherein the applying includes 

combining the rankings according to particular criteria in order to produce 
numerical results providing indications of the likelihood of the attempted intrusions 
relative to the corresponding elements in the telecommunications signaling 
network. 

20 20. The method of claim 1 7 wherein the reporting includes 

reporting a most vulnerable node and a most vulnerable link in the 
telecommunications signaling network. 
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AMENDED CLAIMS 

[received by the International Bureau on 20.December 1999 (20.12.99); 
original claims 1 ,2,4,5,7,1 1 and 17 replaced by amended claims bearing the 
same number; new claims 21 to 26 added; remaining claims unchanged (5 pages)] 

1. An apparatus for providing indications of attempted intrusion in a 
telecommunications signaling network, comprising: 

means for receiving messages related to communications in the 
telecommunications signaling network; 

means for applying intrusion rules to the messages in order to detect anomalies 

in the messages; 

means for classifying the detected anomalies according to particular criteria; 

and 

means for reporting an indication of the classifications of the detected 

anomalies. 

2. The apparatus of claim 1 wherein the receiving means includes means 
for receiving predefined test messages. 

3. The apparatus of claim 1 wherein the receiving means includes means 
for parsing and formatting the message as required for the application of the intrusion rules. 

4. The apparatus of claim 1 wherein the applying means includes means 
for comparing the messages with information related to a known protocol for the 
telecommunications signaling network. 

5. The apparatus of claim 1 wherein in the reporting means includes 
means for presenting in a user interface a topological representation of a portion of the 
telecommunications signaling network. 

6. The apparatus of claim 5 wherein the reporting means includes means 
for presenting in the user interface indications of alarms representing the attempted 
intrusions. 

7. An apparatus for determining a vulnerability of a telecommunications 

signaling network to attempted intrusions, comprising: 
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means for receiving rankings for particular parameters related to elements of 
the telecommunications signaling network; 

means for applying vulnerability rules to the rankings in order to determine a 
likelihood of an attempted intrusion into the corresponding elements of the 
telecommunications signaling network, including means for determining a particular type of 
vulnerability of the corresponding elements; and 

means for reporting an indication of the likelihood of the attempted intrusions, 
including means for determining, based upon the particular type of vulnerability, an action • 
affecting the corresponding elements in order to reduce the likelihood of the attempted 
intrusion in the corresponding elements. 

8 . The apparatus o f claim 7 wherein the receiving means includes means 
for presenting a user interface for receiving the rankings. 

9. The apparatus of claim 7 wherein the applying means includes means 
for combining the rankings according to particular criteria in order to produce numerical 
results providing indications of the likelihood of the attempted intrusions relative to the 
corresponding elements in the telecommunications signaling network. 

10. The apparatus of claim 7 wherein the reporting means includes means 
for reporting a most vulnerable node and a most vulnerable link in the telecommunications 
signaling network. 

11. A method for providing indications of attempted intrusion in a 
telecommunications signaling network, comprising; 

receiving messages related to communications in the telecommunications 

signaling network; 

applying intrusion rules to the messages in order to detect anomalies in the 

messages; 

classifying the detected anomalies according to particular criteria; and 
reporting an indication of the classifications of the detected anomalies. 
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12. The method of claim 1 1 wherein the receiving includes receiving 
predefined test messages. 

13. The method of claim 1 1 wherein the receiving includes parsing and 
formatting the messages as required for the application of the intrusion rules. 

14. The method of claim 1 1 wherein the applying includes comparing the 
messages with information related to a known protocol for the telecommunications signaling 
network. 

15. The method of claim 1 1 wherein the reporting includes presenting in a 
user interface a topological representation of a portion of the telecommunications signaling 
network. 

16. The method of claim 1 5 wherein the reporting includes presenting in 
the user interface indications of alarms representing the attempted intrusions. 

17. A method for determining a vulnerability of a telecommunications 
signaling network to attempted intrusions, comprising: 

receiving rankings for particular parameters related to elements of the 

telecommunications signaling network; 

applying vulnerability rules to the rankings in order to determine a likelihood 
of an attempted intrusion into the corresponding elements of the telecommunications 
signaling network, including determining a particular type of vulnerability of the 

corresponding elements; and 

reporting an indication of the likelihood of the attempted intrusions, including 
determining, based upon the particular type of vulnerability, an action affecting the 
corresponding elements in order to reduce the likelihood of the attempted intrusion in the 
corresponding elements. 

18. The method of claim 17 wherein the receiving includes presenting a 
user interface for receiving the rankings. 
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19. The method of claim 17 wherein the applying includes combining the 
rankings according to particular criteria in order to produce numerical results providing 
indications of the likelihood of the attempted intrusions relative to the corresponding 
elements in the telecommunications signaling network. 

20. The method of claim 1 7 wherein the reporting includes reporting a 
most vulnerable node and a most vulnerable link in the telecommunications signaling 
network. 

21. The apparatus of claim 1 wherein the reporting means includes means 
for generating, based upon the intrusion rules, a time-stamped listing of the classifications of 
anomalies and the corresponding messages. 

22. The apparatus of claim 1 wherein the reporting means includes means 
for generating statistics, based on particular criteria, concerning the messages. 

23 . An apparatus for providing indications of attempted intrusion in a 
telecommunications signaling network, comprising: 

means for receiving a first message related to communications in the 
telecommunications signaling network and referring to a particular link in the network; 

means for applying an intrusion rule to the first message in order to detect 
anomalies in the first message, including determining if a second message of a predefined 
type was previously detected on the particular link; and 

means for reporting an indication of the detected anomalies. 

24. The method of claim 1 1 wherein the reporting includes generating, 
based upon the intrusion rules, a time-stamped listing of the classifications of anomalies and 
the corresponding messages. 

25. The method of claim 1 1 wherein the reporting includes generating 
statistics, based on particular criteria, concerning the messages. 
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26. A method for providing indications of attempted intrusion in a 
telecommunications signaling network, comprising: 

receiving a first message related to communications in the telecommunications 
signaling network and referring to a particular link in the network; 

applying an intrusion rule to the first message in order to detect anomalies in 
the first message, including determining if a second message of a predefined type was 
previously detected on the particular link; and 

reporting an indication of the detected anomalies. 
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